On 02/21/2011 06:34 PM, James Antill wrote:
---
yum/rpmsack.py | 12 +++++++++---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/yum/rpmsack.py b/yum/rpmsack.py
index 3830339..4e9835d 100644
--- a/yum/rpmsack.py
+++ b/yum/rpmsack.py
@@ -71,9 +71,15 @@ class RPMInstalledPackage(YumInstalledPackage):
# Prevent access of __foo__, _cached_foo etc from loading the header
if varname.startswith('_'):
raise AttributeError, "%s has no attribute %s" % (self, varname)
-
- self.hdr = val = self._get_hdr()
- self._has_hdr = True
+
+ if varname != 'hdr': # Don't cache the hdr, unless explicitly requested
+ # Note that we don't even cache the .blah value, but looking up
the
+ # header is _really_ fast so it's not obvious any of it is worth
it.
+ # This is different to prco etc. data, which is loaded separately.
+ val = self._get_hdr()
+ else:
+ self.hdr = val = self._get_hdr()
+ self._has_hdr = True
The question to me is, is there actually ever a "valid" case to cache
the header in the package object? If somebody asks fo po.hdr, they
already get a reference to it, and can then do whatever they please with
it. Eg
h = po.hdr
if h['foo']:
...blah...
if h['bar']:
...blech...
s = h['something']
If the header is "cached" in the object as in patch, it will remain in
memory for the lifetime of the object, while the caller is probably (but
see below) not interested in it after grabbing what they want. If the
header is not cached, it'll fall out of memory as soon as it goes out of
scope in the caller. Yum cannot possibly know what a caller might want
here, so it'd make sense to let the caller decide: if the caller wants
to keep it, let it stash it someplace for keeping.
So if the caching doesn't make much of a difference speed-wise, AFAICS
it might just as well always do 'return self._get_hdr()' and never store
a reference to the header.
- Panu -
_______________________________________________
Yum-devel mailing list
[email protected]
http://lists.baseurl.org/mailman/listinfo/yum-devel
