bpo-46712: Share global string identifiers in deepfreeze#31261
Conversation
Sorry, something went wrong.
kumaraditya303
force-pushed
the
global-strings
branch
from
a173ee9 to
3bd4e2a
Compare
February 10, 2022 14:44
|
Extrapolating the list of global strings dynamically is a good idea. It would be best to do it in a separate PR. I've done so in gh-31346. |
Sorry, something went wrong.
Instead of manually enumerating the global strings in generate_global_objects.py, we extrapolate the list from usage of _Py_ID() and _Py_STR() in the source files. This is partly inspired by gh-31261. https://bugs.python.org/issue46541
kumaraditya303
force-pushed
the
global-strings
branch
from
470037f to
e959ed6
Compare
February 24, 2022 07:50
gvanrossum
left a comment
gvanrossum
left a comment
There was a problem hiding this comment.
LGTM.
I looked at some of the generated output and this feels like it's a good improvement.
Sorry, something went wrong.
gvanrossum
left a comment
gvanrossum
left a comment
There was a problem hiding this comment.
Thanks. Waiting for the tests to run once more.
(Also, please go fix the interning error handling, even if you disagree.)
Sorry, something went wrong.
Okay, will create a PR tomorrow. |
Sorry, something went wrong.
|
Thanks Kumar! It's nice to see us regain some of the space costs of deep-freezing modules. |
Sorry, something went wrong.
Where appropriate, deepfreeze.c now uses `&_Py_ID(blah)` references instead of locally defining constants. This saves some space.
Since bpo-46541, the global strings are statically allocated so they can now be referenced by deep-frozen modules just like any other singleton. Sharing identifiers with deepfreeze will reduce the duplicated strings hence it would save space.
See faster-cpython/ideas#218
See faster-cpython/ideas#230
https://bugs.python.org/issue46712