Repository navigation
Builds of large DDK-based workspaces are slower and retain more memory since #1405 #1545
Description
Since #1405 turned Scope and Export into Xbase / JvmModelInferrer languages, Eclipse builds of large DDK-based workspaces allocate much more, keep more memory alive, and do more work after git branch switches. In a long IDE session this compounds into GC pressure, and the effect seems strongest on Windows with Microsoft Defender scanning every file the builders write.
Measurements
These are headless Eclipse runs on a synthetic downstream-shaped workspace (L: 98 projects, 59 .scope, 59 .export, 939 .xtend), with the stock Xtext builder, alternating git checkout between two branches that differ only in Java/Xtend files. There are 2 runs per variant on macOS. Wall times were too noisy on that machine to quote, so the table shows counters and memory.
| 1e0a5c8 (2026-06-29) | v19.2.0 | master + fixes below | |
|---|---|---|---|
| full build: allocated | 50.5 GB | 75.2 GB (+49%) | 61.2 GB |
| full build: live set afterwards | 402 MB | 634 MB | 398 MB |
| per branch switch: allocated | 6.1 GB | 6.8 GB | 6.1 GB |
per branch switch: .export re-processed |
0 | 2 | 0 |
| live-set growth per switch (20 switches, M workload) | 0.3 MB | 7.9 MB | 0.3 MB |
Causes found and fixes (draft PRs)
- A thread-local leak in
ExportJvmModelInferrerkeeps the last export resource's whole builder resource set alive. Fixed in the R12 PR. - Scope/Export generation rebuilds an all-EPackages type resolver per expression, a project class loader per method body, and uncached genmodel lookups. Fixed in the Tier A PR, with byte-identical output.
- Java-only changes re-queue and regenerate
.exportfiles, because Xbase records the EMF interfaces as imported names. Fixed in the R1 PR, which is for discussion. - What remains after these fixes is about +20% full-build allocation. That is the inherent cost of Scope/Export being full Xbase languages. Whether they need to be is a separate design question.
A before/after measurement of each PR on the affected Windows machine is in progress. The PRs stay drafts until it is in.
🤖 Generated with Claude Code
Activity
joaodinissf commentedon Sep 25, 2026
Draft PRs:
Each is based on master on its own. A before/after benchmark of each on the affected Windows machine is running; the PRs stay drafts until its results are in.
🤖 Generated with Claude Code
joaodinissf commentedon Sep 25, 2026
Benchmark results from the affected platform (Windows 11, 16 cores, Microsoft Defender on), using the same synthetic workspace and harness as the macOS numbers above: 33 runs, each started only on a quiet machine, 0 error markers.
1. macOS vs Windows (@gerdleon): the same workload, harness and DDK builds (M workload, stock builder, 4 GB heap; medians over 3 quiet rounds on both machines):
.exportre-processed, live setThe build does exactly the same work on both machines; Windows spends about 4× the wall time doing it. Defender's engine was busy at 21–51% of a core throughout. Proportionally the DDK regression is the same on both (at L a full build got ~60% slower from 2026-06-29 to v19.2.0: +169 s on Windows, 288 → 457 s; +52 s on macOS, 89 → 141 s, indicative only), but in absolute terms it costs about 3× more on Windows.
2. The regression at scale and the fixes (@rubenporras): L workload (98 projects, 59
.scope/.export, 939.xtend; stock Xtext builder), on Windows:(master is 20 commits past v19.2.0, so the last column is not fix-only; point 3 is.)
3. Fix-only, under heap pressure (master vs master + the three PRs; M workload, 1.2 GB heap, 20 branch switches): full build 154 → 110 s (−29%), branch switch 15.3 → 11.3 s (−26%), first switch 19.7 → 12.4 s (−37%), live-set growth 7.8 → 0.2 MB per switch, peak working set 1.63 → 1.36 GB.
4. At a comfortable 4 GB heap the per-PR wall-time differences on Windows are within noise; the allocation, live-set and files-written effects reproduce the macOS numbers exactly. The fixes pay off where large downstream workspaces live: big workspaces, tight heaps, Windows.
Still open: at L, a full build still allocates ~20% more than before #1405. That's the inherent cost of Scope/Export being Xbase languages, and worth a separate discussion.
🤖 Generated with Claude Code