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 ncoghlan
Recipients eric.araujo, flox, ncoghlan, rhettinger
Date 2010-08-09.04:52:41
SpamBayes Score 7.6091155e-08
Marked as misclassified No
Message-id <AANLkTinqRrkgoizBxvp_YSz_a5UohgiU3AJA1ZnXVnM8@mail.gmail.com>
In-reply-to <1281328152.15.0.700739725336.issue9396@psf.upfronthosting.co.za>
Content
On Mon, Aug 9, 2010 at 2:29 PM, Raymond Hettinger
<report@bugs.python.org> wrote:
> I did find a simple way to dynamically resize the maxcache, but did not apply it yet.   Will look at more applications to see if it is really needed.
>
> Nick, thanks for the great ideas.  These changes simplified the code where they were applied and resulted in a smarter caching strategy.

The reason I mentioned the dynamic sizing specifically was that the
discussions where we realised we had all these different caches
floating around had to do with tuning the caching strategy to a
particular application based on speed vs memory trade-offs. While we
can pick a number that is a reasonable default, a server deployment
may want to turn the dial towards faster response times with higher
memory consumption, while an embedded device may want to push the dial
the other way. The smarter caching strategies you added are likely to
help far more than the blunt hammer approach of increasing the cache
size, but the speed/memory trade-off in choosing that size is still a
question that has no universally correct answer.
History
Date User Action Args
2010-08-09 04:52:47ncoghlansetrecipients: + ncoghlan, rhettinger, eric.araujo, flox
2010-08-09 04:52:45ncoghlanlinkissue9396 messages
2010-08-09 04:52:41ncoghlancreate