Good question. I can’t answer right now because I cannot install Python from the Microsoft Store on this computer (It is blocked for security reason). I think I will be able to do that next week.
Conda-forge Python are really very similar to a vanilla Python. Everything should work the same, in particular installating packages with pip, creating a Python venv from the conda installed Python or use pipx from the conda venv.
In contrast, conda venv are not at all Python venv and have actually nothing to do with Python. One can create a conda venv without python. For example conda create -n env-git git.
I’m a bit pessimistic that it will be different with Python installed from the Microsoft Store. I get the issues with conda installed Python and with UV installed Python. This seems like a quite generic issue on this computer.
If it turns out that the issue is related to the fact that Python from the Microsoft Store is not installed, it would be a big issue for tools like conda-forge, UV and Pixi.
For sure, there is an anti virus software running on this computer. I don’t know how to check if it is related to the startup delay when calling some .exe files.
I now think that it is a possible explanation for these startup delay problems. But how can I check that? And can I fix that? And could it be a more general issue affecting other users? I guess so because I didn’t do anything so crazy.
I think conda should be ruled out. I know pip doesn’t work as usual, in a ‘venv’ created with uv (uv pip must be used instead). Conda have extensive documentation about how to create conda envs. It’s not there without good reason. Others’ve encounter much worse problems than a 500ms delay on startup, when trying to use pip normally in a conda env.
Otherwise it occurred to me that if the “fast” Python being compared to is installed on an SSD, but the “slow” venvs are being created on an HDD, there would be noticeable delays.
I would be much less pessimistic than you about conda installed Pythons. What is bad/dangerous with conda is to mix conda and pip installs. But we’ll see when I am able to install Python from the Microsoft Store…
About UV, I used uv venv and uv pip and it gives the same results. The problem is general and related to how black.exe (a .exe wrapper) and python.exe in the virtual environment are created: by modifying precompiled binaries. Then, something on my PC on Windows delays the startup of the application with security checks. (see About .exe wrappers created by frontends when installing wheels on Windows? - #8 by steve.dower)
Everything is of course installed on the same disk so it is not that.
If you’re using uv to make a venv it doesn’t install pip by default, but if you install pip into the environment it should work as usual. It also looks like both of these examples are using the same drive.
I don’t have conda installed here any more, but redoing the tests with UV on my own (Windows 10) machine I see some delay which is expected but nothing like half a second.
Benchmark 1: .\python\cpython-3.13.1-windows-x86_64-none\python.exe -c "pass"
Time (mean ± σ): 18.5 ms ± 0.6 ms [User: 9.4 ms, System: 9.2 ms]
Range (min … max): 17.6 ms … 20.4 ms 20 runs
Benchmark 2: .\tools\black\Scripts\python.exe -c "pass"
Time (mean ± σ): 26.5 ms ± 1.1 ms [User: 13.5 ms, System: 10.5 ms]
Range (min … max): 25.3 ms … 29.1 ms 20 runs
Summary
.\python\cpython-3.13.1-windows-x86_64-none\python.exe -c "pass" ran
1.44 ± 0.07 times faster than .\tools\black\Scripts\python.exe -c "pass"
The numbers are essentially the same if I use python from the regular installer from python.org and compare it to the python.exe from a venv. The python.exe file included in the environments generated by uv venv and python -m venv is actually identical[1], although there are some differences in how the venv is configured.
As you seem to have found on the other thread it does seem to be something else interfering with the startup.
If both are using the same base Python install. ↩︎
The relevance of conda here is that (as far as I know), neither Anaconda nor conda-forge sign the binaries in their packages. So the virus scanners will always treat them as untrusted and do the full range of scans before letting them run.
Binaries from python.org (which I produce) are all signed, including the PowerShell scripts, and we deliberately avoid modifying them (which would break the signature and make things worse). As a result, they don’t get the same level of scanning, and generally start up much faster.
The Store install unfortunately degrades things a little bit, because it has to use some expensive APIs at startup to locate itself, but should be completely exempt from virus scans because it’s gone through the Store verification process already. I’m working on a complete replacement that ought to resolve that side of things, at the expense of bringing back the virus scans. Unfortunately, it’s all a big balancing act.
Best case scenario for startup time is to make your own app, embed the Python embeddable distro, remove any unused extension modules, create your own entry point, and either publish through the Windows Store[1] or sign the whole thing with your own code certificate and make an installer that installs into Program Files. My implementation of the “complete replacement” linked above uses this approach, along with 1-2 other tricks that I know I can get away with (being on the “inside”, as it were), and it works great.
We only need the expensive APIs to emulate what developers expect from CPython. It’s not necessary just to use Python in your app, only if you want stuff like python -m pip install ... to work. ↩︎
This sounds great but I didn’t find a good document where would be explained how to do that, nor a tutorial for a simple case (for example create an application and its installer for something as simple as black[jupyter]). I found 4. Using Python on Windows — Python 3.13.1 documentation but its not very practical so does not help me so much.
Do you know a link towards something useful, maybe just a quite simple real life example for command line application using such strategy?
Depending your antivirus, sometimes you can add an “exception” or “ignore list” or something that excludes the conda directory subtree from scanning. I remember doing this when I used conda on windows as sometimes antivirus programs did do something weird with it (as they did with other equally innocuous programs).
I managed to install Python from the official installer. I didn’t realise that one does not need administrator privileges for that. Indeed Python venv startup is as good as the root Python. But I get the same startup delay (related to antivirus scan) for applications, install with pip or pipx, i.e. black --version is still very slow.
Therefore, official Python binaries improve the situation but does not fix the initial problem (bad UX for programs installed with pipx on Windows).
Yeah, I really need to get around to writing it one day. Though unfortunately, the simplest case is “write a short C (or Rust) program using your choice of about six different libraries”, which isn’t simple enough for most people and also isn’t easy to document, especially when the only case you are responsible for is the lowest-level one
I confirm that the issue of startup delay is due to an antivirus software. Specifically, when I temporary disable the DeepGuard functionality in WithSecure, startup times become more like expected.
