Re: The Default for python -X frozen_modules.
I accidentally a word. "... module's hash and/or *timestamp* and comparing it ..." On 27/09/2021 18:38, Patrick Reader wrote:
How about checking each non-frozen module's hash and/or and comparing it to that of the frozen module? Would that defeat the performance improvement of freezing? Is it just a terrible idea?
On 27/09/2021 17:51, Eric Snow wrote:
We've frozen most of the stdlib modules imported during "python -c pass" [1][2], to make startup a bit faster. Import of those modules is controlled by "-X frozen_modules=[on|off]". Currently it defaults to "off" but we'd like to default to "on". The blocker is the impact on contributors. I expect many will make changes to a stdlib module and then puzzle over why those changes aren't getting used. That's an annoyance we can avoid, which is the point of this thread.
Possible solutions:
1. always default to "on" (the annoyance for contributors isn't big enough?) 2. default to "on" if it's a PGO build (and "off" otherwise) 3. default to "on" unless running from the source tree
Thoughts?
-eric
On 9/27/2021 6:40 PM, Patrick Reader wrote:
I accidentally a word.
"... module's hash and/or *timestamp* and comparing it ..."
On 27/09/2021 18:38, Patrick Reader wrote:
How about checking each non-frozen module's hash and/or and comparing it to that of the frozen module? Would that defeat the performance improvement of freezing? Is it just a terrible idea?
The filesystem access is what hurts the most, so yeah, that check won't even be considered here without a manual opt-in (which is the option Eric is discussing). Cheers, Steve
participants (2)
-
Patrick Reader
-
Steve Dower