Summary
A bounded comparison of python.org CPython 3.14.6 and uv-managed CPython 3.14.0 found nearly identical median startup/import times: 193.609 ms and 195.148 ms. All 20 launches succeeded. This quiet-window test did not reproduce a previously reported multi-second slowdown, so it did not justify a global interpreter change or patch-version downgrade.
Method and collection date
In October 2026, PowerShell 7.6.8 launched exactly 20 sequential child interpreters, alternating python.org and uv, ten times each. There were no warm-up launches, parallel launches, real hook executions or second round.
Each interpreter received -S -c and identical standard-library import code. Python documents -S as disabling automatic site import and its associated initialization [1]. The import set covered argument handling, JSON, filesystem utilities, subprocesses, threading, networking, SQLite and Windows ctypes support. Importing SQLite did not open a database.
A monotonic .NET stopwatch measured parent-observed launch-through-exit wall time, starting just before process creation and ending after process exit. This included creation-call overhead and small output collection costs; it was not a trace-based measurement of creation-to-first-activity time.
The same scratch working directory was used, and PYTHONHOME, PYTHONPATH and PYTHONDONTWRITEBYTECODE were unset. Every run reported the expected interpreter metadata, no_site == 1, exit zero and empty stderr. Caches were not cleared; ordinary cache reads and possible bytecode-cache maintenance remained possible.
Findings
Neither interpreter showed a material advantage
| Interpreter | Runs | Median (ms) | Minimum (ms) | Maximum (ms) | Mean (ms) |
|---|---|---|---|---|---|
| python.org 3.14.6 | 10 | 193.609 | 174.704 | 368.650 | 220.688 |
| uv-managed 3.14.0 | 10 | 195.148 | 150.139 | 337.535 | 209.610 |
Uv was faster in seven of ten adjacent pairs, but its overall median was 1.539 ms slower. The mixed result does not establish an operationally meaningful improvement. Both first runs were retained rather than discarded as warm-up.
Quiet-window results do not resolve load-dependent delays
Boundary snapshots showed seven hook-like Python processes and 27–28 total Python processes. Samples taken before individual launches showed 26–31 Python processes. These are occupancy counts, not launch rates or CPU utilization.
Earlier same-window trace observations in the source reported python.org first-activity-to-exit median 2.3 seconds and maximum 9.0 seconds, compared with about 0.27 seconds for uv. Those earlier observations used a different timing boundary and occurred during heavy hook activity. They cannot be pooled with the present launch-through-exit measurements.
The present result neither reproduces nor refutes a load-dependent slowdown. It does not prove that load was the only cause or that the earlier problem was fixed. Security-scanning involvement and a hypothesis that the most-used interpreter becomes slow remain unverified here; no new Defender trace was collected.
Startup success is not whole-hook compatibility
Both candidates imported the tested Windows standard-library components under -S. Source inspection distinguished the lightweight launcher layer from deferred tasks that required third-party database packages or optional Redis support. Those project environments cannot safely be replaced by a global search-and-replace of interpreter commands.
No third-party installation or real-hook functional test was attempted. Console and GUI sibling executable behavior, complete dependency resolution and every deferred branch were not established by this probe.
Limitations
The comparison used different patch versions, distributions and executable paths. It did not isolate those variables. A patch-matched future candidate would require its own test rather than inheriting these numbers.
Only ten observations per interpreter were collected in one short window. Alternation reduced simple ordering bias but did not control cache state or background activity, and the result cannot resolve small differences or future heavy-load behavior.
The original measurement harness and raw evidence are not public, limiting independent reproduction. The practical conclusion is narrow: do not switch on this evidence alone. If delays recur, compare interpreter paths passively during the actual affected window using existing process traces. Do not manufacture a hook storm or change security protections to force a result. No runtime or configuration change was made in this study.
References
- Python 3.14 command-line documentation,
-S, methodological reference: https://docs.python.org/3.14/using/cmdline.html#cmdoption-S