Pyhton Interpreter Startup time

[David Bolen]

Peter Hansen <peter at engcorp.com> writes:

> I don't recall the OP in the last thread that discussed this
> ever coming back to report on exactly what OS and CPU etc.
> he was using, and whether network issues might be involved,
> etc, so until someone can prove otherwise, I think it's
> safe to assume that anyone with a slow startup on Windows
> has a misconfiguration or is doing something wrong.

I don't think that's a safe assumption.  For example, on a PIII-550
box running NT that I use, the first time I start up Python after a
prolonged absence (typically through a night when a virus scan is run)
it can take several seconds to start.  The same holds true if I switch
versions of Python for comparisons (the first time a new version is
run takes a few seconds).

Subsequent executions of the same version are sub-second (albeit not
always by much).

There's no network issues involved (everything referenced during
startup is local), but to be honest, I'm not surprised, as I can
clearly hear my disk getting hit hard, and expect that absolutely
nothing was in the disk cache related to Python, so getting it loaded
and all the initial startup files loaded simply takes some time.

The fact that I experience similar noticeable delays with loading just
about everything else the first time after the nightly outage (e.g.,
the first time Outlook needs to load in IE to display an HTML message
encounters a very noticeable multi-second delay with heavy disk I/O)
makes me doubly think that the nightly virus scan is flushing just
about everything out of cache.

Similar startups on a PIII-333 running a Gentoo 2.4.x Linux install
definitely "feel" a bit faster.  For example, using "python -v" on
both systems presents the same list of loaded modules (replacing
posix/posixpath with nt/ntpath under Windows) and then an additional
readline load once the interpreter starts under Linux.  However, the
Linux session just streams those module load messages while you can
visually "see" each message coming out in turn with a tiny delay
between them under Windows.  I haven't run timing measurements, but
it's noticeable enough that while they might not be major, I'm
confident they are there.

So for whatever reason, Windows does behave a bit more sluggishly than
Linux in my case.  Maybe it's the use of the DLL with Windows (don't
know if any relocations have to take place) versus the static binary
under Linux.  Maybe it's just slightly better filesystem I/O (my
Windows box may be more fragmented and/or fuller filesystems).
Certainly doesn't affect me in normal operation, but I guess if I was
starting Python very frequently I'd work on it more.

I also don't think there's much room for Python to be at fault at
least in my case - e.g., if anything it's system behavior and not
really local operations Python is performing.

But I don't think it automatically implies that my Windows system is
misconfigured or that I'm doing something wrong.  Of course, my
timings aren't the consistent 5+ second startups that some others have
posted about, in which cases I do agree there might be an unexpected
network dependency or something else amiss.

-- David