pub fn warm_render_thread_pool(languages: &[&str])Expand description
Eagerly initializes state that parallel-render otherwise sets up
lazily on first use: rayon’s global thread pool, syntect’s default
syntax/theme sets, and — for each language in languages — syntect’s
internal per-language setup.
The languages list matters more than it might look: measured directly
(16-core machine, the fixture:large/code-heavy.md perf-lab fixture,
mixed rust/python/javascript), warming only the thread pool made no
measurable difference to the first render (~20ms either way — thread
spawn itself is not the bottleneck here, contrary to an earlier draft of
this function that assumed it was). What did measurably help was also
pre-highlighting the specific languages the fixture actually uses:
first-render time dropped from ~20.4ms to ~14.1ms (~31%). A
language-blind warm-up can’t buy that on its own, because it doesn’t
know which languages your documents contain — pass the ones you expect
(e.g. your editor’s supported-language list, or languages seen in the
user’s recently opened files) to get the real benefit. An empty slice
still warms the thread pool and syntect’s defaults, which is a small,
generically-safe win, just not the dominant one.
Note there is a residual first-render cost (~6-7ms in the same measurement) that persists even after warming the pool, syntect defaults, and every language actually used — this looks like first-touch allocation/OS-level warm-up rather than anything this crate controls, and no combination of arguments to this function removes it.
Call this during application startup, before the first document is opened (e.g. off a splash screen or init routine), to move whichever part of that cost can be moved off a user-visible render. This is purely a matter of when the cost is paid: if you never call this, rendering still works correctly and everything still initializes lazily and correctly on first use (the default “warm on first request” behavior) — this function does not change behavior or output, only timing.
A no-op when parallel-render is not compiled in, so it’s always safe
to call unconditionally regardless of which features a consumer builds
with.