You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One idea that I've heard a few times is a "daemon" mode where there's a server that can execute general Python requests, and a tiny client that just passes arguments to the server. There are lots of problems with this (e.g. dribbling stdout/stderr, tty access, etc.) and it's probably better done as a 3rd party package that certain apps can use. Does anyone know of a general solution like this? (Mypy has a daemon mode that works like this, but the client is still a Python script, so it wouldn't help startup time.)
For this to work the daemon would need to have a pool of VMs that have already started and are ready to execute arbitrary Python code. This implies that a significant amount of time is spent readying the VM before it can start executing. If that is the case, then we should implement some sort of snapshot of an initialized VM #32 (comment)
The difference between the daemon and the snapshot at startup would most likely be insignificant.
If Python is executed frequently, the snapshotted executable will be in the O/S disk cache and loading it will be fast.
If Python is executed infrequently, then the in-memory VM held by the daemon is likely to have been paged out and will be as slow of the snapshotted executable.
The daemon could presumably pre-fork a bunch of processes after importing a bunch of popular modules, a la Instagram (at least on UNIX). Then no snapshot feature would be required. (Not sure what to do for Windows.)
Activity
markshannon commentedon Sep 30, 2021
For this to work the daemon would need to have a pool of VMs that have already started and are ready to execute arbitrary Python code. This implies that a significant amount of time is spent readying the VM before it can start executing. If that is the case, then we should implement some sort of snapshot of an initialized VM #32 (comment)
The difference between the daemon and the snapshot at startup would most likely be insignificant.
If Python is executed frequently, the snapshotted executable will be in the O/S disk cache and loading it will be fast.
If Python is executed infrequently, then the in-memory VM held by the daemon is likely to have been paged out and will be as slow of the snapshotted executable.
gvanrossum commentedon Sep 30, 2021
The daemon could presumably pre-fork a bunch of processes after importing a bunch of popular modules, a la Instagram (at least on UNIX). Then no snapshot feature would be required. (Not sure what to do for Windows.)
markshannon commentedon Oct 4, 2021
My point was that he daemon process offers no performance advantages over the snapshot approach, but is less portable.
I suspect which is simpler to implement depends on your skill set. Personally, I would find the snapshot approach easier to implement.
gvanrossum commentedon Oct 4, 2021
Maybe snapshots can be implemented using the approach from the Alibaba Compiler team (#86).