Measure time to first paint, which is the startup number that matters

--version measures a process that exits before doing any work. On a pty the
tty shell emits its first byte at 20 ms and settles at 50 ms; the gui takes
~330 ms to map its window, and that is the latency worth noticing.

Of the gui's 330 ms, ~95% is CPU and only ~30 ms is waiting. Profiled warm and
killed before the map: pardes-gui 28.5%, libc 20.7%, ld-linux 11.9%, libudev
10.3%, the nvidia stack ~21%. Cutting across all of those, DWARF unwinding is
20.9% of samples -- the Debug allocator capturing six frames per allocation,
the same cost the previous change found, and now the largest single slice.

Two of my own measurements were wrong and are corrected here. An earlier
~510 ms figure was an artifact: the probe redirected HOME, so the nvidia
shader cache was cold and the driver recompiled every launch. And deferring
SDL_INIT_GAMEPAD past the first frame, on the theory that libudev's 10% was
gamepad enumeration, changed the map time not at all (320-366 ms either way)
and libudev only 10.3% -> 9.6%: that work belongs to SDL_INIT_VIDEO bringing
up Wayland seats. It is reverted rather than kept as an unmeasurable win.

So nothing in the editor's own logic is slow to start. What is left is the
Debug allocator and the GPU stack, and the only lever on either is the build
mode -- which is not worth tripling a ten-minute build for.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

0 files changed, 0 insertions, 0 deletions