Hi,
First, I think common routines are great. More DRY is always good.
Second, my personal feeling is that when you see a hard-coded in-memory
cache like this, it's probably something that should be moved to be
behind a more generic caching framework that allows for different
backends such as memcache for larger deployments.
If you're interested in something like that, I'm sure it would be useful.
Cheers,
On 23/01/14 16:07, Shawn Hartsock wrote:
I would like to have us adopt a memoizing caching library of some kind
for use with OpenStack projects. I have no strong preference at this
time and I would like suggestions on what to use.
I have seen a number of patches where people have begun to implement
their own caches in dictionaries. This typically confuses the code and
mixes issues of correctness and performance in code.
Here's an example:
We start with:
def my_thing_method(some_args):
# do expensive work
return value
... but a performance problem is detected... maybe the method is
called 15 times in 10 seconds but then not again for 5 minutes and the
return value can only logically change every minute or two... so we
end up with ...
_GLOBAL_THING_CACHE = {}
def my_thing_method(some_args):
key = key_from(some_args)
if key in _GLOBAL_THING_CACHE:
return _GLOBAL_THING_CACHE[key]
else:
# do expensive work
_GLOBAL_THING_CACHE[key] = value
return value
... which is all well and good... but now as a maintenance programmer
I need to comprehend the cache mechanism, when cached values are
invalidated, and if I need to debug the "do expensive work" part I
need to tease out some test that prevents the cache from being hit.
Plus I've introduced a new global variable. We love globals right?
I would like us to be able to say:
@memoize(seconds=10)
def my_thing_method(some_args):
# do expensive work
return value
... where we're clearly addressing the performance issue by
introducing a cache and limiting it's possible impact to 10 seconds
which allows for the idea that "do expensive work" has network calls
to systems that may change state outside of this Python process.
I'd like to see this done because I would like to have a place to
point developers to during reviews... to say: use "common/memoizer" or
use "Bob's awesome memoizer" because Bob has worked out all the cache
problems already and you can just use it instead of worrying about
introducing new bugs by building your own cache.
Does this make sense? I'd love to contribute something... but I wanted
to understand why this state of affairs has persisted for a number of
years... is there something I'm missing?
--
Stephen Gran
Senior Systems Integrator - theguardian.com
Please consider the environment before printing this email.
------------------------------------------------------------------
Visit theguardian.com
On your mobile, download the Guardian iPhone app theguardian.com/iphone and our iPad edition theguardian.com/iPad
Save up to 57% by subscribing to the Guardian and Observer - choose the papers you want and get full digital access.
Visit subscribe.theguardian.com
This e-mail and all attachments are confidential and may also
be privileged. If you are not the named recipient, please notify
the sender and delete the e-mail and all attachments immediately.
Do not disclose the contents to another person. You may not use
the information for any purpose, or store, or copy, it in any way.
Guardian News & Media Limited is not liable for any computer
viruses or other material transmitted with or as part of this
e-mail. You should employ virus checking software.
Guardian News & Media Limited
A member of Guardian Media Group plc
Registered Office
PO Box 68164
Kings Place
90 York Way
London
N1P 2AP
Registered in England Number 908396
--------------------------------------------------------------------------
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
