[Python-Dev] A fast startup patch (was: Python startup time)
Glenn Linderman
v+python at g.nevcal.com
Sat May 5 14:25:00 EDT 2018
More information about the Python-Dev mailing list
Sat May 5 14:25:00 EDT 2018
- Previous message (by thread): [Python-Dev] A fast startup patch (was: Python startup time)
- Next message (by thread): [Python-Dev] A fast startup patch (was: Python startup time)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 5/5/2018 10:30 AM, Toshio Kuratomi wrote: > On Fri, May 4, 2018, 7:00 PM Nathaniel Smith <njs at pobox.com > <mailto:njs at pobox.com>> wrote: > > What are the obstacles to including "preloaded" objects in regular > .pyc files, so that everyone can take advantage of this without > rebuilding the interpreter? > > > Would this make .pyc files arch specific? Lots of room in the __pycache__ folder. As compilation of the .py module proceeds, could it be determined if there is anything that needs to be architecture specific, and emit an architecture-specific one or an architecture-independent one as appropriate? Data structures are mostly bitness-dependent, no? But if an architecture-specific .pyc is required, could/should it be structured and named according to the OS conventions also: .dll .so .etc ? Even if it doesn't contain executable code, the bytecode could be contained in appropriate data sections, and there has been talk about doing relocation of pointer in such pre-compiled data structures, and the linker _already_ can do that sort of thing... -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20180505/435c0211/attachment-0001.html>
- Previous message (by thread): [Python-Dev] A fast startup patch (was: Python startup time)
- Next message (by thread): [Python-Dev] A fast startup patch (was: Python startup time)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-Dev mailing list