[issue45661] [meta] Freeze commonly used stdlib modules.

[Guido van Rossum]

Guido van Rossum  added the comment:

Deep-freezing is definitely not a miracle cure. We should continue to trim or 
delay unneeded imports (like Christian just did for setuptools' 
_distutils_hack).

What *would* be a miracle cure would be if we could deep-freeze the module 
contents after it has *executed*. But that is much harder in general, since two 
executions (even on the same platform) could result in different module 
contents (e.g. conditionally defining something based on environment contents).

Instagram's Cinder has something that works for this, strict modules 
(https://github.com/facebookincubator/cinder#strict-modules). It is a complex 
system! But if we could do this it could really speed up a lot of imports 
tremendously. (Though still at the cost of binary size increase.)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45661] [meta] Freeze commonly used stdlib modules.

[Kumar Aditya]

Kumar Aditya  added the comment:

Can you elaborate a bit about "This can have negative affects for performance" 
as I think freezing modules has only one downside of increasing binary size ?

> For WASM builds we want to make the wasm binary as small as possible.

If WASM would become an officially supported platform then there can be a patch 
to disable freezing on such platforms otherwise I don't see how because of WASM 
we cannot deepfreeze for other platforms which benefit from it.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45661] [meta] Freeze commonly used stdlib modules.

[Christian Heimes]

Christian Heimes  added the comment:

Deep freezing is not a miracle cure for startup performance issues. Every 
additional frozen module increases the size of the main binary / shared 
library. This can have negative affects for performance and usability, too. For 
WASM builds we want to make the wasm binary as small as possible.

--
nosy: +christian.heimes

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45661] [meta] Freeze commonly used stdlib modules.

[Inada Naoki]

Inada Naoki  added the comment:

I don't against deep freezing functools and contextlib.
But I think we should optimize and utilize zipimport or something similar, 
because we can not deep-freeze all stdlib or 3rd party libraries.

See also: 
https://github.com/faster-cpython/ideas/discussions/158#discussioncomment-1857198

--
nosy: +methane

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45661] [meta] Freeze commonly used stdlib modules.

[Kumar Aditya]

Kumar Aditya  added the comment:

functools and contextlib are very common so they should be deep-frozen. 
warnings and re would be nice to do.

--
nosy: +gvanrossum, kumaraditya303

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45661] [meta] Freeze commonly used stdlib modules.

[Eric Snow]

Eric Snow  added the comment:

One to consider that isn't necessarily used that commonly is sysconfig.  
However, that could also involve freezing the "sysconfigdata" file (without 
needing to expose it as a module).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45661] [meta] Freeze commonly used stdlib modules.

[Eric Snow]

New submission from Eric Snow :

We're already freezing modules needed for bootstrapping the runtime, as well as 
the modules imported during startup. [1][2]  We're also planning on freezing 
argparse. [3]  There may be other modules (or files) worth freezing (assuming 
we don't just freeze the entire stdlib, which would have some potential 
downsides).

This issue is meant to cover the broader idea.  The work to actually freeze 
modules should be handled in separate issues.


[1] https://bugs.python.org/issue45020
[2] https://bugs.python.org/issue45654
[3] https://bugs.python.org/issue45660

--
components: Build
messages: 405239
nosy: FFY00, eric.snow
priority: normal
severity: normal
status: open
title: [meta] Freeze commonly used stdlib modules.
type: behavior
versions: Python 3.11

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com