About .exe wrappers created by frontends when installing wheels on Windows?

[pf_moore (Paul Moore)]

@oscarbenjamin

I can’t quite tell if you are saying “I” in the sense of hypothetically being someone else who has this AV problem or if you do mean your (Paul’s) actual computer takes 2-5 seconds to run black but doesn’t when running ruff.

I was speaking from the point of view of someone with the performance issue @paugier had described. I don’t have that problem myself, and as far as I’m concerned I have never found the performance of Python applications shipped via pipx or similar to be a problem.

Sorry for being unclear.

@oscarbenjamin

This is much less than 2-5 seconds but still there is a consistent 50x startup difference between black and ruff (even though black is apparently “compiled”).

I see that as well, on Windows. But black is still fast enough (227 milliseconds on my PC) that it doesn’t matter in practice to me. Steve was quoting 2-5 second startup times caused by AV. Again, I’ve never seen that myself, but what I’m trying to establish is whether that 2-5 second overhead is exclusive to Python programs, or if it’s just a feature of “unsigned executables” in general.

@steve.dower

there may just be too many hypotheticals here

Very probably

Let me ask a non-hypothetical question. You say you see 2-5 second delays when running unsigned executables. On that system, do black and ruff have the same 2-5 second delay, or does black see a significantly longer delay (twice as much - 4-10 seconds - for example)?

Because my point is that unless Python is demonstrably worse than non-Python executables on a system with an AV causing that sort of overhead, I don’t think it’s something we should be worrying about solving. A developer who is concerned about that situation can solve it for Rust or C code (by signing the executable) and they can also solve it for Python (albeit with a bit more effort, by creating an executable and signing it, and distributing that executable).

@steve.dower

Yeah, we’ve never figured out how to strip the stdlib (and importantly, the extension modules) for a specific app properly. So a Python app simply just loads more bytes off disk when you launch it.

That’s not true for .exe wrappers (which is what I thought we were talking about here) as they are extremely small executables that just forward to the Python interpreter. Speeding up the startup time of the Python interpreter is a worthy goal, but not something that would explain the different startup times between black and python -m black (the example reported by @paugier here).

@steve.dower

I have no idea what this means either.

The version of black I have isn’t compiled - it’s just a standard entry point wrapper that runs the black.patched_main function, as defined here.

@steve.dower

Though it probably shows more benefit if you do more than just --version - it wouldn’t surprise me if black --version has loaded everything it needs (because “put all your imports at the top of the file”) while ruff --version hasn’t even loaded anything yet.

Agreed - but comparing ruff against black isn’t the real question here. I confused the issue by mentioning ruff, as an example of a program built in Rust that wasn’t signed, not as an example of something that should have comparable performance to a Python program.

The question @paugier raised was why black ran slower than python -m black. No-one knows why that is^[1], and the only plausible explanation anyone has come up with is AV programs and unsigned executables.

---

1. there’s no difference on my PC, so it seems to be related to the environment, not Python itself ↩︎