provide startup time to ready log point and associated benchmark#22581
provide startup time to ready log point and associated benchmark#22581tilladam wants to merge 2 commits into
Conversation
Record when the server is constructed and, at the first completed cache
priming -- when the workspace is loaded and indexed and the editor becomes
usable -- log "workspace loaded and indexed in {elapsed}". rust-analyzer has
no "ready in Xs" line today; this makes slow startups diagnosable straight
from RA_LOG and in bug reports.
Disclosure: prototyped with assistance from Claude (Anthropic); changes
reviewed and owned by the committer.
rustbot
added
the
S-waiting-on-review
`analysis-stats` measures the batch analysis path but never exercises the `main_loop` startup flow (workspace load -> became-quiescent -> cache priming), so startup-ordering regressions there -- serial priming, redundant workspace re-fetches -- are invisible to the existing metrics. Under `RA_METRICS=1`, emit the time-to-ready (added in the previous commit) as a machine-readable `METRIC:startup/time_to_primed:<ms>:ms` line on stderr, and add `measure_startup` to the metrics xtask: it drives the real LSP server (initialize/initialized over stdio, with build scripts / proc-macros / check disabled so the number reflects rust-analyzer's own startup work rather than subprocess compile time) and records `startup/<name>/time_to_primed` next to the existing `analysis-stats/<name>/*` metrics for every benchmarked project. No new dependencies and no metrics-workflow changes. Disclosure: prototyped with assistance from Claude (Anthropic); changes reviewed and owned by the committer.
tilladam
force-pushed
the
internal/startup-time-to-ready
branch
from
7e73760 to
b2b142a
Compare
|
I'm sorry but I don't think this is worth the extra complexity when we already have a |
|
Thanks for looking at this. The prime-caches subcommand is great for testing the raw database caching, but it bypasses the main_loop completely. It doesn't run the actual LSP server, the VFS progress sync, or the flycheck background tasks. I can be convinced that the benchmark doesn't add a ton of value, since regressions are somewhat more likely to come from the interaction of all those things, rather than the code path the benchmark covers, but I'd argue the log point still makes it quite a bit easier to get timing measurements in a significant spot when profiling the launch experience more holistically, for very modest added complexity. |
|
It still loads all files into the VFS and runs Cargo. We don't have much more than that. But since you disagree, let's ask: @rust-lang/rust-analyzer does someone do want this? |
3 participants
While profiling rust-analyzer startup and workspace initialization I found it useful to get the timing of completed cache priming, when the workspace is loaded and indexed. This patch provides that log point and a benchmark to track it over time.
Disclosure: Anthropic Claude 4.7 built the benchmark, a supposedly qualified human reviewed it and takes responsibility for it.