Skip to content

Builder: let the player choose how much memory a build may take - #1090

Merged
hckrman101 merged 4 commits into
NotRexed:mainfrom
corentinbonjour:builder/build-memory-choice
Nov 10, 2026
Merged

hckrman101 merged 4 commits into
NotRexed:mainfrom
corentinbonjour:builder/build-memory-choice

Conversation

@corentinbonjour

@corentinbonjour corentinbonjour commented Nov 9, 2026 •

Copy link
Copy Markdown
Contributor

A player whose other programs hold a lot of RAM is held near the memory gate's floor of compilers, even when asking for every thread, and has no way to let the build take more. This adds a Build memory choice for that.

What changed

The Windows builder gets a Build memory (GB) menu beside Build workers. Automatic is the default and leaves the free-memory policy as it is. The other choices go in 4 GB steps up to the step at or just above the PC's memory (32 on a 32 GB PC that Windows reports as 31.6).

A number sets HOOKSHOT_MEM_LIMIT_GB for that build's child process. MemoryGate then starts a compile when the needs of the running compilers plus its own fit in that limit, whatever is free. The floor stays the same as Automatic's (up to 4 compilers on Windows, one on Linux), so a small number never runs fewer compilers than Automatic.

The choice is saved in builder-settings.json with the other settings. An update started from the game or the launcher shows no menu, so it selects the saved choice before it runs; without one, or when this PC's menu no longer offers it, it uses Automatic.

Prepare shaders now moves to its own row under both menus: in the 160 px Build workers column its label was cut to "Prepare shaders nov".

The variable also works from the command line and on Linux, which has no menu. It is documented in the readme and CONTRIBUTING.md. A value that is not a finite number above 0 (many, 0, nan, inf, 1e309) falls back to Automatic.

The builder settings with Build workers and Build memory

The build files path is hidden in this screenshot, and the install folder was set to a sample path.

Build memory menu open on a 32 GB PC

Why

Build workers sets how many compilers may run, but the memory gate still decides how many do. A player with a lot of RAM in use by other programs has no way to say the build may take more, and is held near the gate's floor even when asking for every thread.

The trade-off is the player's: past the free memory, Windows pages and the PC slows down, and Linux may stop a compiler. A compiler that fails is already compiled again alone at the end.

How it was tested

  • New tests/test_mem_limit.py, picked up by tests/run_all.py: invalid and non-finite values fall back to the free-memory policy, a limit never reads the free memory, keeps Automatic's floor, compiles wait and resume by the sum of their needs, the floor's compiles start even over the limit, and the countdown's estimate follows the limit.
  • tests/test_mem_gate_leases.py (Keep compile memory reservations per invocation #1047) passes: it now also loads mem_limit_mb and runs with the variable empty.
  • tests/builder_workers: the menu's choices, invalid selections, the value reaching the child process next to the DLSS SDK argument, the saved choice read back, settings saved before this change meaning Automatic and a 64 GB PC offered every step up to 64 (103 checks pass).
  • dotnet build of the builder: 0 warnings, 0 errors.
  • The window opened in preview mode on Windows 11 (screenshots above).
  • tests/test_builder_dlss_update.py passes (25 checks): it compiles UpdateBuild alone, so the saved choice is selected in BeginUpdate, which runs before every UpdateBuild.
  • python -I -B tests/run_all.py on Windows, with the .NET 8 SDK on PATH: the same 63 failures as untouched main at 51de681, none new. On this PC they come from missing tools and symlink rights, and 141 checks are skipped. In CI the failing checks (test_present_ahead, test_present_semaphores, test_nup_out_of_space, test_wayland_libdecor_hint, test_draw_parameters, and the hookshot_vk.dll link) fail on main at 51de681 too.

Not tested: a complete game build or update started with a limit, so there is no measured build time for any limit yet.

Notes

Rebased onto #1047's leases: enter still returns its own lease = object() and running stays keyed by it, so each compile is counted on its own.

Build workers is still not saved, so updates keep Automatic for it, as before.

Refs #502.

corentinbonjour and others added 2 commits November 10, 2026 19:41
Assisted-by: Claude Opus 5.5
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
An update started from the game or the launcher shows no menu, so it
always built with Automatic. The Build memory choice is now saved with
the other builder settings and an update selects it before it runs.

Assisted-by: Claude Opus 5.5
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@corentinbonjour
corentinbonjour force-pushed the builder/build-memory-choice branch from 93b0cb9 to 86ff22c Compare November 10, 2026 18:50
@corentinbonjour

Copy link
Copy Markdown
Contributor Author

Rebased onto main with #1047 and went through the review inline. Screenshots are in the description now: the two menus, and Build memory open on a 32 GB PC. The choice is also saved now, so an update started from the game or the launcher uses it instead of always building with Automatic.

The tick sat in the 160 px Build workers column and its label was cut
to "Prepare shaders nov". It now spans both menus on the row below.

Assisted-by: Claude Opus 5.5
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@corentinbonjour

Copy link
Copy Markdown
Contributor Author

Screenshots, as asked: the builder's settings with both menus (the build files path is hidden and the install folder is a sample path), and Build memory open on a 32 GB PC.

The builder settings with Build workers and Build memory

Build memory menu open on a 32 GB PC

tests/test_builder_dlss_update.py compiles UpdateBuild alone, without
the window's controls, so the selection there broke it. BeginUpdate
runs before every UpdateBuild and already reads the saved settings.

Assisted-by: Claude Opus 5.5
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@hckrman101
hckrman101 merged commit f9ed4ba into NotRexed:main Nov 10, 2026
9 of 11 checks passed
soltros added a commit to soltros/Longshot that referenced this pull request Nov 11, 2026
Adopts and adapts NotRexed/Hookshot#1090 by corentinbonjour, original head d08aaed17bb606c4aacd9f6b7bd5f296151de6f4. Preserve Longshot documentation and reject MB conversion overflow.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant