<br><br><div class="gmail_quote">On Tue, Jul 27, 2010 at 6:43 PM, R. David Murray <span dir="ltr"><<a href="mailto:rdmurray@bitdance.com">rdmurray@bitdance.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Tue, 27 Jul 2010 08:27:35 +0200, Stefan Behnel <<a href="mailto:stefan_ml@behnel.de">stefan_ml@behnel.de</a>> wrote:<br>
> Gregory P. Smith, 27.07.2010 07:40:<br>
> > A max cache size of 100 was too small. I just increased it to 500 in the<br>
> > py3k branch along with implementing a random replacement cache overflow<br>
> > policy. It now randomly drops 20% of the compiled regular expression cache<br>
> > instead of simply dropping the entire cache on overflow.<br>
> ><br>
> > With the regex_v8 benchmark, the better cache replacement policy sped it up<br>
> > ~7% while raising the cache size on top of that (likely meaning the cache<br>
> > was never overflowing) sped it up ~25%.<br>
> ><br>
> > Random replacement without dropping everything at least means apps thrashing<br>
> > the cache degrade much more gracefully.<br>
><br>
> The same algorithm should be helpful in ElementTree's ElementPath module.<br>
<br>
</div>We recently added the old re cache-clearing strategy to<br>
fnmatch, because previously its cache would grow indefinitely.<br>
It sounds like this should be applied there as well.<br>
<br>
That's three...time to figure out how to share the code?<br></blockquote><div><br></div><div>No doubt.</div><div><br></div><div>Its already a standalone _shrink_cache function with unit tests that doesn't care the dictionaries it is shrinking are composed of. Easy enough to move somewhere more useful. Any proposed stdlib locations? I'll be offline on vacation soon so I may not get to it for a couple weeks but feel free to move it without me if anyone is interested.<br>
<br></div><div>-gps</div></div>