Repository navigation
bpo-45696: Deep-freeze - #29118
bpo-45696: Deep-freeze#29118gvanrossum merged 46 commits into
Conversation
Sorry, something went wrong.
Not generating Makefile yet
Still not generating Makefile
You could try to use the bootstrap interpreter to generate sysconfig and pybuilddir.txt: main...tiran:deepfreeze-bootstrap In the long run we might be able to replace PYTHON_FOR_REGEN with bootstrap interpreter, too. |
Sorry, something went wrong.
|
@tiran, Does it look good now? All tests pass. I'll merge origin/main again and re-run the buildbots and then I hope to land this. We'll leave several things to future generations (or at least a later PR):
|
Sorry, something went wrong.
|
🤖 New build scheduled with the buildbot fleet by @gvanrossum for commit 0c9de73 🤖 If you want to schedule another build, you need to add the ":hammer: test-with-buildbots" label again. |
Sorry, something went wrong.
|
The AMD64 FreeBSD buildbot is failing (https://buildbot.python.org/all/#/builders/203/builds/314/steps/3/logs/stdio), and AFAICT the cause is that its Make doesn't understand $<. Any suggestions? This part of Makefile.pre.in is generated code, so I could just expand it in the code generator (Tools/scripts/freeze_modules.py), like I had before. Or is there a trick to get this to work on FreeBSD? |
Sorry, something went wrong.
|
I was not aware that bmake has a different syntax for autovars than gmake. I only develop with GNU make. I cannot find a common syntax that works with BSD make and GNU make. You have to go back to the old system. I'm sorry for the extra work I caused. |
Sorry, something went wrong.
|
🤖 New build scheduled with the buildbot fleet by @gvanrossum for commit 3e881031b14dc98f7d2b579e6b06c151df886333 🤖 If you want to schedule another build, you need to add the ":hammer: test-with-buildbots" label again. |
Sorry, something went wrong.
|
🤖 New build scheduled with the buildbot fleet by @gvanrossum for commit f40d138 🤖 If you want to schedule another build, you need to add the ":hammer: test-with-buildbots" label again. |
Sorry, something went wrong.
This gains 10% or more in startup time for `python -c pass` on UNIX-ish systems. The Makefile.pre.in generating code builds on Eric's work for bpo-45020, but the .c file generator is new. Windows version TBD.
This gains 10% or more in startup time for `python -c pass` on UNIX-ish systems. The Makefile.pre.in generating code builds on Eric's work for bpo-45020, but the .c file generator is new. Windows version TBD.
…0 KB space (GH-31074) This reduces the size of the data segment by **300 KB** of the executable because if the modules are deep-frozen then the marshalled frozen data just wastes space. This was inspired by comment by @gvanrossum in #29118 (comment). Note: There is a new option `--deepfreeze-only` in `freeze_modules.py` to change this behavior, it is on be default to save disk space. ```console # du -s ./python before 27892 ./python # du -s ./python after 27524 ./python ``` Automerge-Triggered-By: GH:ericsnowcurrently
See faster-cpython/ideas#84
This seems to be 10% faster than current main[1], so an improvement over Eric's freeze.
Downside: the data segment grows from 490 KB to 1.3 MB. (We could get ~300 KB back by not including the marshalled-frozen data.)
Another downside, for developers: whenever you touch a source file, _bootstrap_python gets rebuilt, and that triggers a rebuild of all the deep-frozen modules. (See comment below for a possible fix.)
Haven't gotten it working on Windows yet. (The magic is disabled there for now.) I might do that in a separate PR.
[1] Measured on an x86 Mac, with lto-pgo, this shaves 1.5-2 msec off a total run time of around 14 msec. I measured by using the subprocess to run python -c pass 100 times.
https://bugs.python.org/issue45696