Guido van Rossum <guido@python.org> writes:
> > Here goes. Everything is relative to 221-base, which is 2.2.1 from Sean's
> > RPM. This is the slowest, so all percentages are negative, and more
> > negative is better. I hope the names are obvious.
> >
> > 221-base +0.00% (obviously)
> > 221-O-base: -9.69%
> > CVS-base: -15.43%
> > CVS-O-base: -23.56%
> > CVS-hacked: -23.66%
> > CVS-O-hacked: -23.70%
> >
> > (Nearly 25% speed up since 221? Boggle. Some of this may be compilation
> > options, I guess)
>
> No, pymalloc sped us up quite a bit.
Yes, this occurred to me after I posted.
pystone is a mystery. It's a fair bit slower but also much more
variable with my patch. Moving trace code out of line helps quite a
bit but it's still ~1% slower.
> > Anyway, it seems I haven't slowed -O down. At some point I might try
> > moving the trace code out of line and see if that has any effect. Not
> > today.
Did do this yesterday, in fact. As I said, it helped pystone a bit,
so I'll upload a separate patch to sf.
[...]
> What's the next step? I haven't had time to review your code. Do you
> want to check it in without further review, or do you want to wait
> until someone can give it a serious look? (Tim's on vacation this
> week so it might be a while.)
I think I'd like to wait for serious review. I'd be surprised if the
patch went out of date at all quickly.
Also, it seems Lib/compiler currently works by generating SET_LINENO
and then builds co_lnotab by scanning for them afterwards. That's not
going to work in the new world, so I should probably think about how
to change it...
Cheers,
M.
--
Finding a needle in a haystack is a lot easier if you burn down
the haystack and scan the ashes with a metal detector.
-- the Silicon Valley Tarot (another one nicked from David Rush)
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