On Sat, Jan 28, 2006 at 11:24:18AM -0600, Andrew Gaffney wrote: > Zac Medico wrote: > >I have reimplemented the previous patch as a normal cache module that adds > >a writable layer on top of the pre-generated metadata. If you'd like to > >try this out (with portage-2.1_preX), simply copy metadata_overlay.py into > >/usr/lib/portage/pym/cache/ and add portdbapi.auxdbmodule = > >cache.metadata_overlay.database to /etc/portage/modules. > > > >I haven't tested this much, but like the previous patch, this shouldn't > >cause any harm. Feedback would be appreciated. > > Portage didn't explode and dep calculation is pretty damn quick with an > empty /var/cache/edb/dep/,
Shouldn't be any difference here, if you are seeing a difference
please time it and post the stats here- it should actually be slightly
slower then a straight flat_hash cache since it's 2 lookups worst case
instead of single lookup.
If you're seeing a difference, indicative of one of the
following
1) I'm a moron and am missing something,
2) innefficiency in flat_hash pulls (since you should be using
metadata for most of the queries, the actual underlying ro cache)
3) something is funky.
> Is it normal for /var/cache/edb/dep/${PORTDIR}/ to be re-created
> (it's still empty) when this new module is in use?
Flat_hash does that up front so it doesn't have to do tests for the
directory on __setitem__ calls; so yes, normal :)
Additional issue here zach pointed out is that the current flat_list
cache format used for rsync metadata/cache doesn't actually bundle
eclass mtimes, so stale detection for eclasses won't work via this.
Part of the reason the metadata class exists (and can handle
flat_list/flat_hash internally on it's own)- until flat_hash is the
rsync tree format, staleness detection won't work for running straight
from $PORTDIR/metadata/cache
~harring
pgpDodbkhjTKl.pgp
Description: PGP signature
