[Python-ideas] Keep free list of popular iterator objects

M.-A. Lemburg mal at egenix.com
Sun Sep 15 15:50:12 CEST 2013


On 15.09.2013 14:09, Antoine Pitrou wrote:
> On Sun, 15 Sep 2013 13:52:39 +0200
> "M.-A. Lemburg" <mal at egenix.com> wrote:
>>> A best-case 15% improvement on a
>>> trivial microbenchmark probably means a 0% improvement on real-world
>>> workloads. Furthermore, using specialized freelists will increase
>>> memory fragmentation and prevent the main allocator from returning
>>> memory to the system.
>>
>> Keeping e.g. a hundred such objects in a free list shouldn't
>> really affect the memory load of the Python interpreter.
> 
> Well, it can. The object allocator uses 256KB arenas, so if each of
> the hundred objects in the free list keeps a different arena alive, we
> are talking about a 25 MB fragmentation overhead.
> 
> Yes, that's a worse case (and irrealistic for common workloads)
> overhead, but the 15% improvement is a best case (and very irrealistic
> for common workloads) performance gain :-)

The trick here is to preallocate the pool of those 100 iterator
objects, so you only use one such arena - hopefully the ones
that's also used for the other free lists :-)

>> A 15% improvement isn't a lot, but such small improvements
>> add up if they are consistent and the net result is an overall
>> performance improvement.
> 
> I've grown skeptical that such small improvements actually "add up" to
> something significant. Performance differences between CPython versions
> can generally be attributed to one or two important changes (hopefully
> improvements :-)) such as e.g. PEP 393, the method lookup cache, or
> new-style classes.

For Python 1.5 I had done a whole serious of such smaller
improvements. The net effect was a speedup of between 20-30%,
so I wouldn't be too skeptical :-)

What's important about such small enhancements is that they
provide consistent speedups and have a sane ratio between
complexity/maintenance overhead and performance improvement.

> Anyway, if there's a non-trivial benchmark that can measure the
> real-world potential of this optimization, it would help the
> discussion :-)

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Sep 15 2013)
>>> Python Projects, Consulting and Support ...   http://www.egenix.com/
>>> mxODBC.Zope/Plone.Database.Adapter ...       http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________
2013-09-11: Released eGenix PyRun 1.3.0 ...       http://egenix.com/go49
2013-09-04: Released eGenix pyOpenSSL 0.13.2 ...  http://egenix.com/go48
2013-09-20: PyCon UK 2013, Coventry, UK ...                 5 days to go

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/


More information about the Python-ideas mailing list