Thomas Camlong
c73b139dbd
PHASE2-FINDINGS.md had grown past 1,200 lines mixing server memory, client rendering, methodology and a long list of rejected experiments, which made it unusable as a reference. Split under docs/perf/: README.md headline results and the change-by-change ratio table SERVER-MEMORY.md what the container's RAM is made of, layer by layer CLIENT-PERFORMANCE.md dashboard cost in Chrome: DOM, fibers, images, paint REJECTED.md ideas implemented, measured and abandoned, with numbers METHODOLOGY.md the tools, and the measurement traps that gave wrong answers PHASE2-FINDINGS.md is now an index so existing links keep working. METHODOLOGY.md is the part worth keeping: every wrong number in this investigation came from an instrument rather than the application, and each trap is written down - snapshots cannot explain peaks, V8 truncates snapshot strings to ~1 KiB, snapshot objects are not live handles, measuring without a forced GC measures V8's growth, taking a CDP snapshot added 134 MiB to the process being measured, per-component React attribution silently returns nothing on a production build, a fixed port can measure a leftover container, and a server-side change that moves a client-side metric means the workload changed.
29 lines
1.5 KiB
Markdown
29 lines
1.5 KiB
Markdown
# Performance findings
|
||
|
||
This file grew past 1,200 lines covering server memory, client rendering, methodology and a long
|
||
list of rejected ideas at once. It has been split by subject under [`docs/perf/`](./docs/perf/):
|
||
|
||
| document | subject |
|
||
| --- | --- |
|
||
| [docs/perf/README.md](./docs/perf/README.md) | Headline results and the change-by-change ratio table |
|
||
| [docs/perf/SERVER-MEMORY.md](./docs/perf/SERVER-MEMORY.md) | What the container's RAM is made of, layer by layer, and what reduced it |
|
||
| [docs/perf/CLIENT-PERFORMANCE.md](./docs/perf/CLIENT-PERFORMANCE.md) | Dashboard cost in Chrome: DOM, fibers, images, paint |
|
||
| [docs/perf/REJECTED.md](./docs/perf/REJECTED.md) | Ideas implemented, measured, and abandoned — with their numbers |
|
||
| [docs/perf/METHODOLOGY.md](./docs/perf/METHODOLOGY.md) | The tools, and the measurement traps that produced wrong answers |
|
||
|
||
## Result in one table
|
||
|
||
Server RAM, merge-base `06724cfeb` vs this branch, two alternated runs per side, cgroup **anonymous**
|
||
memory — the figure that counts against a container limit:
|
||
|
||
| stage | before | after | change |
|
||
| --- | --- | --- | --- |
|
||
| **peak** | 376.6 MiB | **279.3 MiB** | **−26%** |
|
||
| boot idle | 130.5 MiB | **62.4 MiB** | **−52%** |
|
||
| after sign-in | 247.4 MiB | **142.9 MiB** | **−42%** |
|
||
| dashboard loaded | 293.4 MiB | **170.4 MiB** | **−42%** |
|
||
| 4 tabs, 2 boards | 366.5 MiB | **258.2 MiB** | **−30%** |
|
||
| after 2 min idle soak | 323.7 MiB | **200.8 MiB** | **−38%** |
|
||
|
||
No before/after range overlaps at any stage. Cost: **+18% CPU**, solid and non-overlapping.
|