[Python-Dev] Death to WITH_CYCLE_GC

[Tim Peters]

[Tim]
>> There is no such switch now.  There used to be one. ...

[MAL]
> Interesting. I don't recall any discussions about this...

It was a topic on Python-Dev at the time, very brief, possibly consisting of
no more than a "how about this?" msg, and a "yes, and that too" reply from
Guido.

>> ... 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.

> I was talking about NSMALLNEGINTS and NSMALLPOSINTS.

Me too.  They're not there to turn off caching, they're there to tune it.
If you #define them both to 0, you will, as I said, end up using more
memory, not less.  If you #undef them, it will have no effect -- the code
will #define them back to their defaults then.

> 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 ?

I don't know.

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

Ditto.

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

That's platform-dependent.  It's 16 bytes on Win32 using MSVC 6.

> 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.

Why?  Python-Dev is for Python developers, and if nobody here *uses* the
non-feature of being able to compile out cyclic gc, and the hypothetical
people who do use it aren't serious enough about Python to participate here,
there's no paying audience for this continued unused complexity.  If
somebody wants it, they can step up and volunteer to (a) maintain this code,
and (b) test it.  Short of those two happening, it's history.

>> 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.

They can lobby for themselves, provided they still exist.  BTW,
WITHOUT_COMPLEX is the only preprocessor symbol I can think of that was
deliberately intended to make life easier on small platforms (HAVE_UNICODE
may or may not be in that boat -- I don't know why it's there).  Given the
comparatively trivial savings WITHOUT_COMPLEX affords, it hardly seems worth
the bother.  People who have written up the results of serious Python ports
to tiny platforms report needing *major* surgery, far beyond anything these
goofy #ifdefs provide (tiny platforms are, from a std C plus std POSIX view,
deeply broken in many ways).  The best such effort I knew of used to live
here

    http://www.abo.fi/~iporres/python

but that link is dead now, and a Google search doesn't suggest the project
has moved somewhere else.

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

Very true, and I thank you for playing along <wink>.