GeezerVison is showing github.com — Standardise (and publish?) cache handling in standard library · Issue #53642 · python/cpython
Standardise (and publish?) cache handling in standard library #53642Description
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = 'https://github.com/rhettinger'
closed_at = <Date 2010-08-22.08:06:14.022>
created_at = <Date 2010-07-28.11:27:10.412>
labels = ['type-feature', 'library']
title = 'Standardise (and publish?) cache handling in standard library'
updated_at = <Date 2010-08-22.08:51:32.047>
user = 'https://github.com/ncoghlan' bugs.python.org fields:
activity = <Date 2010-08-22.08:51:32.047>
actor = 'eric.araujo'
assignee = 'rhettinger'
closed = True
closed_date = <Date 2010-08-22.08:06:14.022>
closer = 'rhettinger'
components = ['Library (Lib)']
creation = <Date 2010-07-28.11:27:10.412>
creator = 'ncoghlan'
dependencies = ['9567']
files = []
hgrepos = []
issue_num = 9396
keywords = []
message_count = 12.0
messages = ['111790', '113273', '113300', '113374', '113378', '113382', '113383', '113385', '113570', '113580', '113791', '114647']
nosy_count = 5.0
nosy_names = ['rhettinger', 'ncoghlan', 'eric.araujo', 'r.david.murray', 'flox']
pr_nums = []
priority = 'low'
resolution = 'fixed'
stage = 'needs patch'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue9396'
versions = ['Python 3.2'] Activityncoghlan commented on Jul 28, 2010 ContributorAuthor More actions ncoghlan commented on Aug 8, 2010 ContributorAuthor More actions With Raymond adding functools.lru_cache and functools.lfu_cache, it should be possible to use those for the various caches in the standard library.
My only point of concern is that the standard lib caches tend to allow dynamic modification of the max cache size, while the new cache decorators appear to be fixed at the size specified when defining the decorator. rhettinger commented on Aug 8, 2010 I will take a look at the various caches and see if some of their features can be consolidated. It is okay if some need to have their own strategies or situation specific approaches, but you're right that common features should be looked at to see if they make sense in the functools caches.
Am not sure that dynamically changing the maxsize is a generally useful feature (most are set to the largest size that makes sense and not revisited latter), but I will take a look to whether that complicates the code (if it's simple and fast, it may be worth doing). ncoghlan commented on Aug 9, 2010 ContributorAuthor More actions Yeah, I'm not sure the dynamic resizing makes sense in general. I was just pointing it out as something supported by the existing caches that could complicate a consolidation effort. rhettinger commented on Aug 9, 2010 Applied the lru_cache() to fnmatch and re.
See r83874 r83871.
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. ncoghlan commented on Aug 9, 2010 ContributorAuthor More actions On Mon, Aug 9, 2010 at 2:29 PM, Raymond Hettinger
<[email protected]> 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. rhettinger commented on Aug 9, 2010 I was thinking about the problem of developers wanting a different cache size than that provided in standard lib modules.
ISTM that now we've offered caching abilities in functools, a developer can easily add another layer of cache around any API they are interested in. For example, if someone is using thousands of recurring fnmatch patterns, they can write something like:
@functools.lfu_cache(maxsize=10000) # custom fat cache
def fnmatchcase(*args):
return fnmatch.fnmatchcase(*args)
IMO, this beats adding caching controls to lots of APIs that should be focused only on their problem domain. IOW, it is probably not a good idea to add purge() and cache_resize() functions to multiple modules throughout the standard lib.
ISTM, we should just provide basic caching with reasonable space consumption (i.e. not huge) that gives improvements to common use cases (like I've done with the fnmatch and re module) and let programmers with unusual cases add their own caching options rather that be tied into our choice of lru vs lfu or whatnot. ncoghlan commented on Aug 9, 2010 ContributorAuthor More actions On Mon, Aug 9, 2010 at 3:11 PM, Raymond Hettinger
<[email protected]> wrote:
ISTM, we should just provide basic caching with reasonable space consumption (i.e. not huge) that gives improvements to common use cases (like I've done with the fnmatch and re module) and let programmers with unusual cases add their own caching options rather that be tied into our choice of lru vs lfu or whatnot.
A very good point! Perhaps we should note that somewhere? I'm not sure
where though, unless we just mention it in the docs for the relevant
modules..
Going the other way (using a smaller, or no, cache), perhaps in
addition to the new hit/miss attributes, the cache decorators should
expose the original function to allow the cache to be bypassed? rhettinger commented on Aug 10, 2010 Great minds think alike. I was just about to propose that functools.wraps add a standard attribute to point at the underlying function (on the theory that objects should be introspectable). This would allow a standard way to get to the underlying unwrapped functions. merwok commented on Aug 11, 2010 After discussion with RDM on IRC, I’m opening a new report to track this feature request separately. (It’s also a dependency of this bug.) ncoghlan commented on Aug 13, 2010 ContributorAuthor More actions Have we had any luck getting this to play nicely with the buildbots yet? (I lost track of where the last checkin got to). The necessary Modules/Setup change to adjust when _collections is built should have propagated through by now. merwok commented on Aug 22, 2010 Raymond, out of curiosity, can you tell why you removed lfu_cache?
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|