The implementation of string interning uses a dict [1].  It would consume less memory and be a bit simpler if it used a set.

Identifier strings in a program are interned.  If you have a large program with a lot of code, this makes for a large dictionary.

Experimenting with changing this to use a set on 2.7 found ~22k savings on an interactive interpreter startup.  Measuring it on a huge application showed a few hundred k saved.

[1]: https://hg.python.org/cpython/file/3.5/Objects/unicodeobject.c#l1579

Presumably it would involve using private set APIs to make this work, right? Since normally you can't look up the actual value in a set, just check for existence?

Here's an example patch against 2.7 by nnorwitz that we're currently testing.

Why did you remove _Py_ReleaseInternedStrings()? It looks like a big memory leak when Python is embedded.

Because it was only called from within an "#ifdef __INSURE__" which we weren't using.  I called it an "example" patch for a reason.  Updating that function to deal with the set instead of dict seems wise.

Ironically... a few days after we did this we may have just found reason to put _Py_ReleaseInternedStrings() back and use it when compiled using clang sanitizers.  (untested)

updated patch:

Don't Py_CLEAR the dummy sentinel value in PySet_Fini. The interned set uses it.  Otherwise it causes problems when re-initializing after a Fini as happens in processes the setup and tear down an embedded interpreter multiple times.

Dicts are hard optimized for string keys due to using them for globals and attributes lookup. Sets are optimized too, but rather for accident. We can be sure that dicts will be always optimized, but set optimization can be eliminated for the sake of simplification or if it will be proven that special casing strings has enough large negative effect on non-string items.

I agree with Serhiy that this should not be done.   IIRC, there were some discussions on python-dev or python-ideas about using sets for interning and the judgment was the dicts are conceptually the right type and that using sets would be hack.  The other thought was that while a set is generally two-thirds the size of dict, the bulk of the space is for the interned strings themselves.

The space for the strings is a fixed cost, the structure used to store them for efficient lookup is the only overhead that can be trimmed and is all in one contiguous allocation.

regardless, i agree, this isn't a large savings. priority low, feel free to drop if it you want.

Since interned strings table can only grow and contains exact strings, other data structure may be more appropriate (for example Modules/hashtable.c).

But for now status quo is good to me.

Serhiy Storchaka added the comment:
>
> Since interned strings table can only grow and contains exact strings,
> other data structure may be more appropriate (for example
> Modules/hashtable.c).
>

FYI this module is not well optimized. I took code and then adapted it for
my needs in tracemalloc. If you want to use it outside, you should check
again that parameters like used buckets/total buckets ratio are well chosen.

GPS: priority low, feel free to drop if it you want.
SS: But for now status quo is good to me.

Marking as closed.  Feel free to open a separate tracker item if you want to pursue the use of Modules/hashtable.c.