[issue34690] Store startup modules as C structures for 20%+ startup speed improvement

[Eric Engeström]

Change by Eric Engeström :


--
nosy: +1ace

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34690] Store startup modules as C structures for 20%+ startup speed improvement

[Paulo Henrique Silva]

Change by Paulo Henrique Silva :


--
nosy: +phsilva

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34690] Store startup modules as C structures for 20%+ startup speed improvement

[Barry A. Warsaw]

Change by Barry A. Warsaw :


--
nosy: +barry

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34690] Store startup modules as C structures for 20%+ startup speed improvement

[Nick Coghlan]

Nick Coghlan  added the comment:

python-dev thread with more discussion of the patch: 
https://mail.python.org/pipermail/python-dev/2018-September/155188.html

Note that my comment above was based on a misunderstanding of what the patch 
does - the module level code still gets executed at import time, what's able to 
be avoided is the unmarshalling costs.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34690] Store startup modules as C structures for 20%+ startup speed improvement

[Nick Coghlan]

Nick Coghlan  added the comment:

Something else this would need is a different name that better distinguishes it 
from the existing frozen modules, which freeze the bytecode rather than the 
resulting module state. (That existing approach avoids the stat overhead, but 
still incurs the module level bytecode execution overhead)

My suggestion would be to use the terms "preexec builtin module" and "preexec 
extension module", as the concept is similar to precompiled bytecode, just 
taken a step further: actually executing the module in advance and caching the 
result, not just compiling it.

This means the preexecuted module can't have any module level conditional logic 
that depends on runtime state if the resulting binary is going to remain 
portable across different environments, but there'd be a lot of standard 
library modules that could satisfy that constraint.

--
nosy: +ncoghlan

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34690] Store startup modules as C structures for 20%+ startup speed improvement

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +xtreak

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34690] Store startup modules as C structures for 20%+ startup speed improvement

[Neil Schemenauer]

Neil Schemenauer  added the comment:

I commented on python-dev but maybe it is better to keep discussion here.  
Could we make the frozenmodules thing into a dynamically loaded module?  Then 
you could have support for end users making their own.  E.g. a command-line 
param that lists a set of DLLs from which to load frozen modules from.  Then, 
if the command-line is not provided, we load from .pyc as per default.  If it 
is provided, we dlopen (or whatever) the DLLs and give the nice performance 
benefits.

Like Guido, I want to see the toolchain to build the frozenmodules thing.

--
nosy: +nascheme

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34690] Store startup modules as C structures for 20%+ startup speed improvement

[Larry Hastings]

Larry Hastings  added the comment:

As Neil points out on python-dev, my "improvement" should have been multiplied 
by 100, like 20.924239043734505 % instead of 0.20924239043734505 %, etc.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34690] Store startup modules as C structures for 20%+ startup speed improvement

[Larry Hastings]

Larry Hastings  added the comment:

I should add that there were two novel test failures in the regression test 
suite: test_module and test_site.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34690] Store startup modules as C structures for 20%+ startup speed improvement

[Eric Snow]

Change by Eric Snow :


--
nosy: +eric.snow

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34690] Store startup modules as C structures for 20%+ startup speed improvement

[Eric V. Smith]

Change by Eric V. Smith :


--
nosy: +eric.smith

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34690] Store startup modules as C structures for 20%+ startup speed improvement

[Larry Hastings]

Change by Larry Hastings :


--
keywords: +patch
pull_requests: +8745
stage: needs patch -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34690] Store startup modules as C structures for 20%+ startup speed improvement

[Larry Hastings]

New submission from Larry Hastings :

This patch was sent to me privately by Jeethu Rao at Facebook.  It's a change 
they're working with internally to improve startup time.  What I've been told 
by Carl Shapiro at Facebook is that we have their blessing to post it publicly 
/ merge it / build upon it for CPython.  Their patch was written for 3.6, I 
have massaged it to the point where it minimally works with 3.8.

What the patch does: it takes all the Python modules that are loaded as part of 
interpreter startup and deserializes the marshalled .pyc file into precreated 
objects stored as static C data.  You add this .C file to the Python build.  
Then there's a patch to Python itself (about 250 lines iirc) that teaches it to 
load modules from these data structures.

I wrote a quick dumb test harness to compare this patch vs 3.8 stock.  It runs 
a command line 500 times and uses time.perf_counter to time the process.  On a 
fast quiescent laptop I observe a 21-22% improvement:

cmdline: ['./python', '-c', 'pass']
500 runs:

sm38
  average time 0.006302303705982922
  best 0.006055746000129147
 worst 0.0081656558437

clean38
  average time 0.007969956444008858
  best 0.007829047999621253
 worst 0.00881221542109

improvement 0.20924239043734505 %

cmdline: ['./python', '-c', 'import io']
500 runs:

sm38
  average time 0.006297688038004708
  best 0.00598076593309
 worst 0.0072462130010535475

clean38
  average time 0.007996319670004595
  best 0.0078091849991324125
 worst 0.009175700999549008

improvement 0.21242667903482038 %


The downside of the patch: for these modules it ignores the Python files on 
disk--it doesn't even stat them.  If you add stat calls you lose half of the 
speed improvement.  I believe they added a work-around, where you can set a 
flag (command-line? environment variable? I don't know, I didn't go looking for 
it) that tells Python "don't use the frozen modules" and it loads all those 
files from disk.


I don't propose to merge the patch in its current state.  I think it would need 
a lot of work both in terms of "doing things the way Python does it" as well as 
just code smell (the serializer is implemented in both C and Python and jumps 
back and forth, also the build process for the serialized modules is pretty 
tiresome).

Is it worth working on?

--
assignee: larry
components: Interpreter Core
messages: 325401
nosy: larry
priority: normal
severity: normal
stage: needs patch
status: open
title: Store startup modules as C structures for 20%+ startup speed improvement
type: enhancement
versions: Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com