On Sun, Sep 16, 2018 at 1:24 PM, Antoine Pitrou <solipsis at pitrou.net> wrote: > I think it's of limited interest if it only helps with modules used > during the startup sequence, not arbitrary stdlib or third-party > modules. > This should help any use-case that is already using the freeze module already bundled with CPython. Third-party code, like py2exe, py2app, pyinstaller, and XAR could build upon this to create applications that start faster. > To give an idea, on my machine the baseline Python startup is about 20ms > (`time python -c pass`), but if I import Numpy it grows to 100ms, and > with Pandas it's more than 200ms. Saving 4ms on the baseline startup > would make no practical difference for concrete usage. > Do you have a feeling for how many of those milliseconds are spend loading bytecode from disk? If so standalone executables that contain numpy and pandas (and mercurial) would start faster > I'm ready to think there are other use cases where it matters, though. > I think so. I hope you will, too :-) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20180917/9567ef14/attachment.html>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4