<div dir="ltr">On Fri, May 4, 2018 at 5:14 AM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><span class="gmail-"><div class="gmail_quote">This definitely seems interesting, but is it something you'd be seeing us being able to take advantage of for conventional Python installations, or is it more something you'd expect to be useful for purpose-built interpreter instances? (e.g. if Mercurial were running their own Python, they could precache the heap objects for their commonly imported modules in their custom interpreter binary, regardless of whether those were standard library modules or not).</div></span></div></div></blockquote><div><br></div><div>Yes, this would be a win for a conventional Python installation as well.  Specifically, users and their scripts would enjoy a reduction in cold-startup time.</div><div><br></div><div>In the numbers I showed yesterday, the version of the interpreter with our patch applied included unmarshaled data for the modules that always appear on the sys.modules list after an ordinary interpreter cold-start.  I believe it is worthwhile to including that set of modules in the standard CPython interpreter build.  Expanding that set to include the commonly imported modules might be an additional win, especially for short-running scripts.</div><div> <br></div></div></div></div>