This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author pitrou
Recipients collinwinter, gregory.p.smith, jcea, jyasskin, lauromoura, nnorwitz, phsilva, pitrou, rhettinger, tzot
Date 2009-02-13.18:37:23
SpamBayes Score 1.2850887e-08
Marked as misclassified No
Message-id <1234550287.7339.39.camel@fsol>
In-reply-to <1234548840.32.0.696647130726.issue2459@psf.upfronthosting.co.za>
Content
Hello Collin,

Thanks for taking a look.

> I don't see the changes to the lnotab format being a roadblock; just
> mention it in NEWS. Likewise, the pure-Python compiler package shouldn't
> be a high priority; your changes to that package look good enough.

Well, I have good news: the fixes to the pure Python compiler have been
accepted and committed by Neil Schemenauer in r69373.

> I'm seeing encouraging speed-ups out of this (with gcc 4.3.1 x86_64,
> compiling Python as 64-bit):
> Django templates (render a 150x150 table 100 times):
> Min: 0.595 -> 0.589: 0.94% faster
> Avg: 0.599 -> 0.591: 1.30% faster
> 
> Spitfire templates (render a 1000x1000 table 100 times):
> Min: 0.751 -> 0.729: 2.98% faster
> Avg: 0.753 -> 0.730: 3.09% faster

Not a tremendous speedup but not totally insignificant either.
(I see you like Spitfire :-))

> None of the apps I've benchmarked are negatively impacted. I only have
> two minor comments. Please commit this.

Before committing I want to know what to do with the new jump opcodes,
with respect to the alternative proposal I've made in #4715.
Ideally, I should fold the #4715 patch back into the present patch,
since I think the #4715 approach is more thought out.
History
Date User Action Args
2009-02-13 18:37:26pitrousetrecipients: + pitrou, nnorwitz, collinwinter, rhettinger, gregory.p.smith, jcea, tzot, jyasskin, lauromoura, phsilva
2009-02-13 18:37:24pitroulinkissue2459 messages
2009-02-13 18:37:23pitroucreate