| Summary: | Build consumes too much memory on 8gb M1 | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Kimmo Kinnunen <kkinnunen> |
| Component: | Tools / Tests | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | Normal | CC: | ap, emw, webkit-bug-importer |
| Priority: | P2 | Keywords: | InRadar |
| Version: | WebKit Local Build | ||
| Hardware: | Mac (Apple Silicon) | ||
| OS: | macOS 11 | ||
|
Description
Kimmo Kinnunen
2021-06-17 08:53:26 PDT
I'm not sure if there is much we can do about the underlying issue of how heavy our compile tasks are.
In my most recent testing, on a 20-core Mac Studio, the system peaked at 32GB memory usage during a build. For comparison, on a 24-core / 16 GB linux system I recently built WebKitGTK on, I had to limit the number of concurrent jobs to 14 to avoid running out of memory.
On Apple platforms, we can control the amount of parallelism, but only (easily) from build scripts. I'm not convinced we should do this project-wide, because:
- On systems like yours, building from Make would magically be faster than building the same scheme/targets in Xcode.
- Less parallelism would be available for non-memory-intensive parts of the build, like copying files and generating code.
That said, you can customize it yourself via defaults:
defaults write com.apple.dt.Xcode IDEBuildOperationMaxNumberOfConcurrentCompileTasks 6
or
make ... ARGS="-IDEBuildOperationMaxNumberOfConcurrentCompileTasks 6"
Yeah, it's mostly not a real problem.. I was thinking the realistic solution would be to set IDEBuildOperationMaxNumberOfConcurrentCompileTasks as something like min(#cores, #GBs - 2) but if Xcode doesn't support it it's unrealistic to get it done. |