<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:#954F72;
        text-decoration:underline;}
.MsoChpDefault
        {mso-style-type:export-only;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style></head><body lang=EN-US link=blue vlink="#954F72"><div class=WordSection1><p class=MsoNormal><span lang=EN-AU>ā€œ</span>the data shows that a focused change to address file system inefficiencies has the potential to broadly and transparently deliver benefit to users without affecting existing code or workflows.ā€</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>This is consistent with a Node.js experiment I heard about where they compiled an entire application in a single (HUGE!) .js file. Reading a single large file from disk is quicker than many small files on every significant file system Iā€™m aware of. Is there benefit to supporting import of .tar files as we currently do .zip? Or perhaps having a special fast-path for uncompressed .zip files?</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Top-posted from my Windows phone</p><p class=MsoNormal><o:p> </o:p></p><div style='mso-element:para-border-div;border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal style='border:none;padding:0in'><b>From: </b><a href="mailto:carl.shapiro@gmail.com">Carl Shapiro</a><br><b>Sent: </b>Monday, May 7, 2018 14:36<br><b>To: </b><a href="mailto:njs@pobox.com">Nathaniel Smith</a><br><b>Cc: </b><a href="mailto:ncoghlan@gmail.com">Nick Coghlan</a>; <a href="mailto:python-dev@python.org">Python Dev</a><br><b>Subject: </b>Re: [Python-Dev] A fast startup patch (was: Python startup time)</p></div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>On Fri, May 4, 2018 at 6:58 PM, Nathaniel Smith <<a href="mailto:njs@pobox.com" target="_blank">njs@pobox.com</a>> wrote:</p><div><div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><div><div><p class=MsoNormal>What are the obstacles to including "preloaded" objects in regular .pyc files, so that everyone can take advantage of this without rebuilding the interpreter?</p></div></div></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>The system we have developed can create a shared object file for each compiled Python file.  However, such a representation is not directly usable.  First, certain shared constants, such as interned strings, must be kept globally unique across object code files.  Second, some marshaled objects, such as the hashed collections, must be initialized with randomization state that is not available until after the hosting runtime has been initialized.</p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>We are able to work around the first issue by generating a heap image with the transitive closure of all modules that will be loaded which allows us to easily maintain uniqueness guarantees.  We are able to work around the second issue with some unobservable changes to the affected data structures.</p></div><div><p class=MsoNormal> </p></div></div></div></div><p class=MsoNormal>Based on our numbers, it appears there should be some hesitancy--at this time--to changing the format of compiled Python file for the sake of load-time performance.  In contrast, the data shows that a focused change to address file system inefficiencies has the potential to broadly and transparently deliver benefit to users without affecting existing code or workflows. </p><p class=MsoNormal><o:p> </o:p></p></div></body></html>