Startup time
Startup latency is paid every launch: on each CLI invocation, every serverless
cold start, every dev-server reload. It is dominated by loading and initializing
code the process does not need yet. Cut it by deferring what can wait,
precompiling what must run, and pruning what should not be there at all.
Method
- Profile the import and init cost, do not guess. Use
python -X importtime, node --cpu-prof on boot, or a startup trace. Find the modules
that cost the most milliseconds at load, before the first useful line of work
runs.
- Make heavy imports lazy. Move a slow dependency (
pandas, TensorFlow, a
cloud SDK) from the module top level into the function that first needs it. A
CLI that imports everything upfront pays for subcommands it never runs.
- Precompile ahead of time. Ship bytecode with
python -m compileall or a
warmed __pycache__, take a V8 snapshot, or build a GraalVM native image to
skip JIT warmup. Ahead-of-time work trades build time for boot time.
- Prune the dependency tree. Each transitive package is more code to find,
parse, and initialize. Audit with
pipdeptree or npm ls, drop packages
pulled in for a single helper, and replace a heavyweight library with a few
lines where you can.
- Defer connections and warmups past the critical path. Opening database
pools, fetching config over the network, or priming caches at import time
blocks the first response. Do it lazily or in the background after the
process reports ready.
- Measure cold and warm starts separately. For serverless, a fresh
container and a warm invocation differ by an order of magnitude. Time both
and optimize the one that hits your p99: cold start for spiky, bursty
traffic.
Signals
- Does an import-time profile name the expensive modules, or is it a hunch?
- Does an unused subcommand avoid loading the heavy dependency?
- Is anything done at import time that could wait until first use?
- For serverless, did cold-start p99 move, not just warm latency?
Boundaries
Steady-state throughput after warmup is cpu-optimization or concurrency-tuning;
this is the one-time cost to first useful work. Shrinking a browser's JavaScript
parse cost is bundle-size. Build-tool specifics defer to the toolchain in use.
1---2name: startup-time3description: Cut startup latency by deferring heavy imports, precompiling ahead of time, and pruning the dependency tree that loads before first useful work. Use when CLI launch, serverless cold start, or dev-loop boot time is too slow.4---56# Startup time78Startup latency is paid every launch: on each CLI invocation, every serverless9cold start, every dev-server reload. It is dominated by loading and initializing10code the process does not need yet. Cut it by deferring what can wait,11precompiling what must run, and pruning what should not be there at all.1213## Method14151. **Profile the import and init cost, do not guess.** Use `python -X16 importtime`, `node --cpu-prof` on boot, or a startup trace. Find the modules17 that cost the most milliseconds at load, before the first useful line of work18 runs.192. **Make heavy imports lazy.** Move a slow dependency (`pandas`, TensorFlow, a20 cloud SDK) from the module top level into the function that first needs it. A21 CLI that imports everything upfront pays for subcommands it never runs.223. **Precompile ahead of time.** Ship bytecode with `python -m compileall` or a23 warmed `__pycache__`, take a V8 snapshot, or build a GraalVM native image to24 skip JIT warmup. Ahead-of-time work trades build time for boot time.254. **Prune the dependency tree.** Each transitive package is more code to find,26 parse, and initialize. Audit with `pipdeptree` or `npm ls`, drop packages27 pulled in for a single helper, and replace a heavyweight library with a few28 lines where you can.295. **Defer connections and warmups past the critical path.** Opening database30 pools, fetching config over the network, or priming caches at import time31 blocks the first response. Do it lazily or in the background after the32 process reports ready.336. **Measure cold and warm starts separately.** For serverless, a fresh34 container and a warm invocation differ by an order of magnitude. Time both35 and optimize the one that hits your p99: cold start for spiky, bursty36 traffic.3738## Signals3940- Does an import-time profile name the expensive modules, or is it a hunch?41- Does an unused subcommand avoid loading the heavy dependency?42- Is anything done at import time that could wait until first use?43- For serverless, did cold-start p99 move, not just warm latency?4445## Boundaries4647Steady-state throughput after warmup is cpu-optimization or concurrency-tuning;48this is the one-time cost to first useful work. Shrinking a browser's JavaScript49parse cost is bundle-size. Build-tool specifics defer to the toolchain in use.
Amey-Thakur