[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