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/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4