_PyStaticCode_InternStrings is called ~800 times during startup.

[markshannon]

The _Py_Deepfreeze_Init() function calls _PyStaticCode_InternStrings once for each string.

Creating the interned string dict in one go, from the table of static strings would be much faster.
something like this (error checking omitted, and other liberties taken for brevity)

_Py_CreateInternedDict(PyObject **strs, int n) {
   PyDictKeys *table = make_dict_keys(n);
   for (int i = 0; i < n; i++) {
        table->entries[i].key = table->entries[i].value = strs[i];
        table->entries[i].hashcode = strs[i].hash_code;
        // Fix up size and entries here.
   }
   return new_dict(table);
}

All the hash codes will need to be initialized first, but we probably should do that anyway.

[markshannon]

@ericsnowcurrently
@gvanrossum

[gvanrossum]

Maybe @kumaraditya303 is interested in doing this?

[ericsnowcurrently]

Yeah, seems like a good improvement. FWIW, I considered doing this a while back but with a static initializer but it was way too messy.

[kumaraditya303]

What percentage of the startup _PyStaticCode_InternStrings accounts for? @ericsnowcurrently Do you have a flame graph of startup with deepfreeze turned on based on recent main?

[gvanrossum]

All the hash codes will need to be initialized first, but we probably should do that anyway.

This is a bit problematic since the hash codes vary based on the hash seed. I wouldn’t be surprised if this was most of the cost. Please look into that before writing the code.

[markshannon]

The hashes always get initialized, it will be no slower to do them all up front.

[kumaraditya303]

Another thing is if we create a table of strings it should also include the global identifier strings not just deepfreeze strings.

[gvanrossum]

The hashes always get initialized, it will be no slower to do them all up front.

My point was that we don't know if this rearrangement of the code is going to have any effect. And in particular if the hash computation is expensive, it may dominate the cost, so rearranging the code won't help. So yes, we need a flame graph or something like that to show where the time is spent.

[AraHaan]

I agree with listing the strings so then allocations can be faster.