Author rhettinger
Recipients Aaron.Meurer, BreamoreBoy, amaury.forgeotdarc, anacrolix, asvetlov, brechtm, eric.snow, ezio.melotti, giampaolo.rodola, jcea, josh.r, kachayev, meador.inge, pitrou, poke, rhettinger, scoder, serhiy.storchaka, skrah
Date 2014-08-07.01:19:01
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1407374341.78.0.713035340894.issue14373@psf.upfronthosting.co.za>
In-reply-to
Content
> I think we should increase the priority of this issue.

I don't think so at all.  The LRU cache we have now is plenty efficient for its intended use cases (caching I/O bound functions and expensive functions).  If is only unsuitable for functions that are already blazingly fast.  

Getting the locks right and carefully looking for re-entrancy issues is important.  Also, keeping the memory footprint of the keys small is important (if people didn't care about space, they wouldn't be using an LRU at all).

I will look at this but currently have much higher priorities elsewhere in Python (adding C accelerators for tricky code is less important for the time being -- we have a long time until 3.5).
History
Date User Action Args
2014-08-07 01:19:01rhettingersetrecipients: + rhettinger, jcea, amaury.forgeotdarc, pitrou, scoder, giampaolo.rodola, ezio.melotti, asvetlov, poke, skrah, meador.inge, anacrolix, Aaron.Meurer, BreamoreBoy, eric.snow, serhiy.storchaka, brechtm, kachayev, josh.r
2014-08-07 01:19:01rhettingersetmessageid: <1407374341.78.0.713035340894.issue14373@psf.upfronthosting.co.za>
2014-08-07 01:19:01rhettingerlinkissue14373 messages
2014-08-07 01:19:01rhettingercreate