[Python-3000] C API for ints and strings
Guido van Rossum
guido at python.org
Mon Sep 10 18:38:40 CEST 2007
On 9/9/07, Nicholas Bastin <nick.bastin at gmail.com> wrote:
> On 9/9/07, Guido van Rossum <guido at python.org> wrote:
> > On 9/9/07, Nicholas Bastin <nick.bastin at gmail.com> wrote:
> > > I'm not suggesting that Python handle small ints itself and then farm
> > > out large integer computations, I'm suggesting that since we've
> > > already coalesced small ints into 'large' ones, we might want to
> > > review the performance implications of that decision, and possibly
> > > consider that other people have already solved this problem. Clearly
> > > GMP appears to fail on a technical level, but there might be other
> > > options worth investigating.
> >
> > The performance problems that are affecting us most are for
> > small-value ints. The old PyInt type has many custom optimizations to
> > help. I think we could do worse than re-introducing some of the same
> > tricks, retargeted to PyLong (which never got much attention for
> > small-value performance).
>
> I did redo my benchmark using 200 as the increment number instead of
> 1, to duck any impact from the interning of small value ints in 2.6,
> and it made no discernible difference in the results.
I'm sorry, I've lost context. I'm not at all clear at this point what
benchmark you might have ran.
Note that when I said "small values" I meant (in part) anything that
fits in a Python long -- while there's a special cache in 2.x for ints
< 100, there's also a special allocator that outperforms the obmalloc
allocator.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
More information about the Python-3000
mailing list