GeezerVison is showing github.com — Share global string identifiers in deepfreeze · Issue #90868 · python/cpython
Share global string identifiers in deepfreeze #90868Description
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = <Date 2022-02-25.18:08:29.439>
created_at = <Date 2022-02-10.14:18:03.087>
labels = ['3.11', 'performance']
title = 'Share global string identifiers in deepfreeze'
updated_at = <Date 2022-03-28.09:14:38.402>
user = 'https://github.com/kumaraditya303' bugs.python.org fields:
activity = <Date 2022-03-28.09:14:38.402>
actor = 'kumaraditya'
assignee = 'none'
closed = True
closed_date = <Date 2022-02-25.18:08:29.439>
closer = 'gvanrossum'
components = []
creation = <Date 2022-02-10.14:18:03.087>
creator = 'kumaraditya'
dependencies = []
files = []
hgrepos = []
issue_num = 46712
keywords = ['patch']
message_count = 7.0
messages = ['413003', '413005', '414028', '414295', '415665', '415811', '415882']
nosy_count = 4.0
nosy_names = ['gvanrossum', 'eric.snow', 'Dennis Sweeney', 'kumaraditya']
pr_nums = ['31261', '31596', '31637', '32061', '32152']
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'resource usage'
url = 'https://bugs.python.org/issue46712'
versions = ['Python 3.11'] Activitykumaraditya303 commented on Feb 10, 2022 ContributorAuthor More actions 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 kumaraditya303 commented on Feb 10, 2022 ContributorAuthor More actions I have refactored generate_global_objects.py, and now instead of hard-coding every identifier manually, it now scans *.c files extracts the identifiers used in it and then generate the header file. This has multiple advantages:
- No need to manually add identifiers, as soon as it is used in a c file it is added to the global identifiers struct.
- It simplifies the codegen a lot.
- Remove the need of special casing certain file for checking now it is just a set of identifiers and auto removes unused global strings.
gvanrossum commented on Feb 25, 2022 ericsnowcurrently commented on Mar 1, 2022 sweeneyde commented on Mar 21, 2022 In bpo-47067, there was concern about the addition of the makefile target from PR 31637:
regen-global-objects: regen-deepfreeze
After a new &_Py_ID(__orig_class__) is added to Objects/genericaliasobject.c, running make regen-global-objects starts
gcc -pthread -c [snipped] -DPy_BUILD_CORE -o [Objects/genericaliasobject.o](https://github.com/python/cpython/blob/main/Objects/genericaliasobject.o) [Objects/genericaliasobject.c](https://github.com/python/cpython/blob/main/Objects/genericaliasobject.c)
which fails with a compilation error because that identifier is not yet defined. Is there a good way to convince make to regenerate the global objects without this sort of circular dependency? Am I missing a step? ericsnowcurrently commented on Mar 22, 2022
After a new &_Py_ID(__orig_class__) is added to Objects/genericaliasobject.c, running make regen-global-objects starts
gcc -pthread -c [snipped] -DPy_BUILD_CORE -o [Objects/genericaliasobject.o](https://github.com/python/cpython/blob/main/Objects/genericaliasobject.o) [Objects/genericaliasobject.c](https://github.com/python/cpython/blob/main/Objects/genericaliasobject.c)
which fails with a compilation error because that identifier is not yet defined. Is there a good way to convince make to regenerate the global objects without this sort of circular dependency? Am I missing a step?
I'm looking into this. A temporary workaround is to run Tools/scripts/generate-global-objects.py directly. ericsnowcurrently commented on Mar 23, 2022
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|