[Python-Dev] Death to WITH_CYCLE_GC

[M.-A. Lemburg]

Tim Peters wrote:
> [MAL]
> 
>>Then why do we have a switch to optionally remove the Unicode
>>support ?
> 
> 
> I don't know, although I've asked that question myself.  People used to be
> frightened of the Unicode database sizes; I'm not sure they are anymore.
 >
 >
>>or for disabling interning of strings ?
> 
> 
> There is no such switch now.  There used to be one.  Ditto for whether to
> cache hash values.  Ditto whether to "cache-align" hash table entries.  At
> the time those were nuked, Guido also said he wanted COUNT_ALLOCS to
> disappear (and to act as if it were always #define'd in a Py_TRACE_REFS
> build), but nobody has gotten to that yet.

Interesting. I don't recall any discussions about this...

>>or for caching small integers ?
> 
> 
> There isn't a switch for that either, although there are two undocumented
> symbols you can #define such that if their sum is <= 0, small ints waste
> *more* memory than if you leave the code alone.  There's no way to disable
> the unbounded and immortal int free list, and never was.

I was talking about NSMALLNEGINTS and NSMALLPOSINTS.

>>>>How much memory footprint would removing the #ifdefs
>>>>cause on average ?
>>>
> 
>>>6, give or take.
>>
> 
>>6 what ? snakes, rabbits, swallows ?
> 
> 
> You asked an unanswerable (not to mention unparseable) question, I gave a
> useless yet accurate answer -- if you can rephrase your question in a way
> that can be answered, attach whatever units you need to make 6 exactly
> correct <wink>.  Although note that since WITH_CYCLE_GC has been #define'd
> by default since it was introduced, removing its #ifdefery would have no
> effect on default builds.

Ok, let's make it parseable then:

a) When removing the GC code from the code base by #undef'ing
    WITH_CYCLE_GC, how much smaller is the Python interpreter ?

b) ..., how is pybench affected by this (speedup/slowdown/
    unnoticable) ?

c) ..., how many bytes per object are saved for container objects
    which are GC aware ?

If we're talking about just a few kB in interpreter size
and only a few kB worth of list and tuples, then removing
is fine. If we're talking about 100kBs, then you ought to
reconsider the move.

>>I'm missing a concise concept here :-)
>>
>>If you want to make life hard for people who want to customize
>>the interpreter, then you should remove *all* such #ifdefs. If
>>not, then having the #ifdefs adds important meta-information
>>to the code.
> 
> 
> If you don't personally use a specific preprocessor symbol routinely, I
> won't accept your bare assertion that it makes life easier for anyone.

I personally know that developers which have tried to create
a trimmed down version of the interpreter did like the #ifdefs
for removing certain parts like e.g. the complex numbers very
much. I'm just lobbying for them.

After all, someone has to give you a hard time ;-)

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
_______________________________________________________________________
eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,...
Python Consulting:                               http://www.egenix.com/
Python Software:                    http://www.egenix.com/files/python/