On Thu Apr 17 2014 at 3:21:49 PM, Guido van Rossum <gu...@python.org> wrote:
> I'm sorry to keep asking dumb questions, but your description didn't job > my understanding of what you are comparing here. What is slower than what? > Startup where the stdlib is entirely in a zip file is slower than the status quo of reading from files. IOW it looks like speeding up startup from an import perspective requires either freezing modules -- for about a 10% boost -- or some fundamental change in import that no one has thought of yet. -Brett > > > On Thu, Apr 17, 2014 at 11:47 AM, Brett Cannon <bcan...@gmail.com> wrote: > >> Because people keep bringing it up, below is the results of hacking up >> the interpreter to include a sys.path entry for ./python35.zip instead of >> hard-coding to /usr/lib/python35.zip and simply zipped up Lib/ recursively. >> TL;DR, zipimport performance no longer measures up (probably because of >> stat caching and such that importlib introduced). >> >> ### normal_startup ### >> >> Min: 0.510211 -> 2.667958: 5.23x slower >> >> Avg: 0.521073 -> 2.694876: 5.17x slower >> >> Significant (t=-1129.54) >> >> Stddev: 0.00478 -> 0.01274: 2.6681x larger >> >> >> ### startup_nosite ### >> >> Min: 0.304090 -> 0.908059: 2.99x slower >> >> Avg: 0.312374 -> 0.921807: 2.95x slower >> >> Significant (t=-797.79) >> >> Stddev: 0.00372 -> 0.00667: 1.7956x larger >> >> >> >> -Brett >> >> On Mon Apr 14 2014 at 5:51:23 PM, Brett Cannon <bcan...@gmail.com> wrote: >> >>> It was realized during PyCon that since we are freezing importlib we >>> could now consider freezing all the modules to cut out having to stat or >>> read them from disk. So for day 1 of the sprints I I decided to hack up a >>> proof-of-concept to see what kind of performance gain it would get. >>> >>> Freezing everything except encodings.__init__, os, and _sysconfigdata, >>> it speeds up startup by 11% compared to default. Compared to 2.7 it shaves >>> 14% from the slowdown (27% slower vs. 41% slower). The full results are at >>> the end of the email. >>> >>> Now the question is whether the maintenance cost of having to rebuild >>> Python for a select number of stdlib modules is enough to warrant putting >>> in the effort to make this work. My guess is the best approach would be >>> adding a Lib/_frozen directory where any modules that we treat like this >>> would be kept to act as a reminder that you need to rebuild for them (I >>> would probably move importlib/_boostrap.py as well to make this consistent). >>> >>> Thoughts? >>> >>> >>> -------------------------------------- >>> >>> default vs the freezing: >>> >>> ### normal_startup ### >>> >>> Min: 0.524812 -> 0.473339: 1.11x faster >>> >>> Avg: 0.534403 -> 0.481245: 1.11x faster >>> >>> Significant (t=61.80) >>> >>> Stddev: 0.00466 -> 0.00391: 1.1909x smaller >>> >>> >>> ### startup_nosite ### >>> >>> Min: 0.307359 -> 0.291939: 1.05x faster >>> >>> Avg: 0.317667 -> 0.300156: 1.06x faster >>> >>> Significant (t=26.29) >>> >>> Stddev: 0.00543 -> 0.00385: 1.4099x smaller >>> >>> --------- >>> >>> 2.7 vs the freezing: >>> >>> ### normal_startup ### >>> >>> Min: 0.367571 -> 0.465264: 1.27x slower >>> >>> Avg: 0.374404 -> 0.476662: 1.27x slower >>> >>> Significant (t=-90.26) >>> >>> Stddev: 0.00313 -> 0.00738: 2.3603x larger >>> >>> >>> ### startup_nosite ### >>> >>> Min: 0.164510 -> 0.290544: 1.77x slower >>> >>> Avg: 0.169833 -> 0.301109: 1.77x slower >>> >>> Significant (t=-286.30) >>> >>> Stddev: 0.00211 -> 0.00407: 1.9310x larger >>> >>> --------- >>> >>> As a baseline, 2.7 vs default: >>> >>> ### normal_startup ### >>> >>> Min: 0.368916 -> 0.521758: 1.41x slower >>> >>> Avg: 0.376784 -> 0.531883: 1.41x slower >>> >>> Significant (t=-172.82) >>> >>> Stddev: 0.00423 -> 0.00474: 1.1207x larger >>> >>> >>> ### startup_nosite ### >>> >>> Min: 0.165156 -> 0.309090: 1.87x slower >>> >>> Avg: 0.171516 -> 0.319004: 1.86x slower >>> >>> Significant (t=-283.45) >>> >>> Stddev: 0.00334 -> 0.00399: 1.1948x larger >>> >> >> _______________________________________________ >> Python-Dev mailing list >> Python-Dev@python.org >> https://mail.python.org/mailman/listinfo/python-dev >> > Unsubscribe: >> https://mail.python.org/mailman/options/python-dev/guido%40python.org >> >> > > > -- > --Guido van Rossum (python.org/~guido) >
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com