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 rhettinger
Recipients asvetlov, barry, bdkearns, brett.cannon, ezio.melotti, jcea, ncoghlan, pitrou, pjenvey, rhettinger, sbt, serhiy.storchaka, terry.reedy, zzzeek
Date 2013-03-09.23:35:19
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1362872119.73.0.172285727499.issue16389@psf.upfronthosting.co.za>
In-reply-to
Content
A few thoughts:

* The LRU cache was originally intended for IO bound calls not for tight, frequently computationally bound calls like re.compile.

* The Py3.3 version of lru_cache() favors size optimizations (i.e. it uses only one dictionary instead of the two used by OrderedDict and keyword arguments are flattened into a single list instead of a nested structure).  Also, the 3.3 version assures that __hash__ is not called more than one for a given key (this change helps objects that have a slow hash function and it helps solve a reentrancy problem with recursive cached function calls).  The cost of these changes is that _make_key is slower than it was before.

* I had hoped to get in a C version of _make_key before Py3.3 went out but I didn't have time.  Going forward, the lru_cache() will likely have a C-implementation that is blindingly fast.  

* For the re module, it might make sense to return to custom logic in the re modue that implements size limited caching without the overhead of 1) LRU logic, 2) general purpose argument handling, 3) reentrancy or locking logic, and 4) without statistics tracking.
History
Date User Action Args
2013-03-09 23:35:19rhettingersetrecipients: + rhettinger, barry, brett.cannon, terry.reedy, jcea, ncoghlan, pitrou, pjenvey, ezio.melotti, zzzeek, asvetlov, sbt, serhiy.storchaka, bdkearns
2013-03-09 23:35:19rhettingersetmessageid: <1362872119.73.0.172285727499.issue16389@psf.upfronthosting.co.za>
2013-03-09 23:35:19rhettingerlinkissue16389 messages
2013-03-09 23:35:19rhettingercreate