By my reading of that output (thanks for including it all), the ones that jump out to me as “huh?” are:
- most of
-m(runpy) is actuallyimport contextlib - most of
import jsonis actuallyimport re - most of
import dataclassesis actuallyimport inspect - most of
import tempfileis actuallyimport shutil - most of
import shutilis actually importing all the compression algorithms
Just from the names, these all seem like things that we could improve in the stdlib (probably by making them lazy), and significantly reduce startup time for a lot of applications. It would be meaningless if the modules were highly related, but these don’t look like that - e.g. it seems entirely feasible to use dataclasses without also using inspect for some other reason, so it’s probably only being imported for a dataclass.
Apart from just names, I’m also looking at cases where the second column is large but the first column is small. That indicates that the module is taking a lot of time because of what it imports, and not because it itself has a lot going on. Most of black’s own modules and dependencies are pretty evenly distributed, even though they take a lot of time - the ones I listed above are spending drastically more time in transitive imports than in their own code.
To bring things back on topic (suggest someone start a new thread if they’re interested in optimising our own imports), the cost of launching the Python application is definitely going to be higher than a fully native application, regardless of AV.