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 Jim.Jewett, Mark.Shannon, benjamin.peterson, giampaolo.rodola, gregory.p.smith, jcea, jcon, pitrou, pjenvey, rhettinger, terry.reedy, vstinner
Date 2012-04-04.14:33:04
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1333549670.3401.3.camel@localhost.localdomain>
In-reply-to <>
> > Also, I don't get your remark about it running in a short time. Your
> > patch AFAICT doesn't need any warm up period to exhibit any
> > improvements.
> What I mean is that the runtime is so short, no one would notice any
> change, so who cares?

None of the benchmarks used here are real-world workloads, so you might
as well claim that they are all irrelevant. But then we'll have a hard
time assessing the consequences of your patch.

> > I don't think we should reduce the size of the method cache. 1024 is not
> > a very large number, and might even be too small for complex OO
> > programs.
> "not very large" or "too small", by what metric?

By the metric of the number of classes and methods in a complex OO
application (for example something based on Twisted or SQLAlchemy).

> > I also think that, apart from the dict storage changes, your patch
> > should strive not to change any other tunables. Otherwise we're really
> > comparing apples to oranges.
> If the implementation changes, shouldn't the tunable parameters be retuned?

Only if there's a reasoning behind it. Perhaps the retuning would have
given the same results without the rest of your patch.
Date User Action Args
2012-04-04 14:33:05pitrousetrecipients: + pitrou, rhettinger, terry.reedy, gregory.p.smith, jcea, vstinner, giampaolo.rodola, pjenvey, benjamin.peterson, Mark.Shannon, jcon, Jim.Jewett
2012-04-04 14:33:04pitroulinkissue13903 messages
2012-04-04 14:33:04pitroucreate