[Python-Dev] startup time repeated? why not daemon

[Nathaniel Smith]

On Jul 20, 2017 14:18, "Eric Snow" <ericsnowcurrently at gmail.com> wrote:

On Thu, Jul 20, 2017 at 11:53 AM, Jim J. Jewett <jimjjewett at gmail.com>
wrote:
> I agree that startup time is a problem, but I wonder if some of the pain
> could be mitigated by using a persistent process.
>
> [snip]
>
> Is it too hard to create a daemon server?
> Is the communication and context switch slower than a new startup?
> Is the pattern just not well-enough advertised?

A couple years ago I suggested the same idea (i.e. "pythond") during a
conversation with MAL at PyCon UK.  IIRC, security and complexity were
the two major obstacles.  Assuming you use fork, you must ensure that
the daemon gets into just the right state.  Otherwise you're leaking
(potentially sensitive) info into the forked processes or you're
wasting cycles/memory.  Relatedly, at PyCon this year Barry and I were
talking about the idea of bootstrapping the interpreter from a memory
snapshot on disk, rather than from scatch (thus drastically reducing
the number of IO events).  From what I gather, emacs does (or did)
something like this.


There's a fair amount of prior art for both of these. The prestart/daemon
approach is apparently somewhat popular in the Java world, because the jvm
is super slow to start up. E.g.:
    https://github.com/ninjudd/drip
The interesting thing there is probably their README's comparison of their
strategy to previous attempts at the same thing. (They've explicitly moved
away from a persistent daemon approach.)

The emacs memory dump approach is *really* challenging. They've been
struggling to move away from it for years. Have you ever wondered why
jemalloc is so much better than the default glibc malloc on Linux?
Apparently it's because for many years it was impossible to improve glibc
malloc's internal memory layout because it would break emacs.

I'm not sure either of these make much sense when python startup is already
in the single digit milliseconds. While it's certainly great if we can
lower that further, my impression is that for any real application, startup
time is overwhelmingly spent importing user packages, not in the
interpreter start up itself. And this is difficult to optimize with a
daemon or memory dump, because you need a full list of modules to preload
and it'll differ between programs.

This suggests that optimizations to finding/loading/executing modules are
likely to give the biggest startup time wins.

-n
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20170720/9bb1b6c8/attachment-0001.html>