[PATCH] performance: disable workaround for an old bug of Python
Yuya Nishihara
yuya at tcha.org
Sun Aug 14 02:14:30 UTC 2016
On Fri, 12 Aug 2016 23:42:38 +0200, Maciej Fijalkowski wrote:
> Well, seems the comment is out of date. I know the issue - the GC got
> triggered every X objects in 2.6, which caused O(n^2) performance when
> allocating lots of objects. These days (since 2.7) it adapts the
> threshold, which means it always amortizes to O(n).
> On Thu, Aug 11, 2016 at 12:36 AM, Matt Mackall <mpm at selenic.com> wrote:
> > It's either fixed in 2.7 or it's not. The primary users of this code are
> > dirstate and obsmarkers, so it should be pretty easy to test. This changeset has
> > a benchmark:
> >
> > changeset: 25675:5817f71c2336
> > user: Pierre-Yves David <pierre-yves.david at fb.com>
> > date: Wed Nov 26 16:58:31 2014 -0800
> > files: mercurial/obsolete.py
> > description:
> > obsstore: disable garbage collection during initialization (issue4456)
I can't say there's measurable win on CPython 2.7, and we have native parser
now. So I'll take this patch, thanks.
$ hg debugobsolete | wc -l
106437
$ hg up 5817f71c2336 # use pure python parser
$ python -m timeit -r10 \
-s 'from mercurial import obsolete, scmutil; svfs = scmutil.vfs(".hg/store")' \
'obsolete.obsstore(svfs)'
(Python 2.6.9, GC disabled)
10 loops, best of 10: 714 msec per loop
(Python 2.6.9, GC enabled)
10 loops, best of 10: 746 msec per loop
(Python 2.7.12+, GC disabled)
10 loops, best of 10: 699 msec per loop
(Python 2.7.12+, GC enabled)
10 loops, best of 10: 703 msec per loop
The result of timeit wasn't stable.
More information about the Mercurial-devel
mailing list