Re: [gentoo-portage-dev] VDB double reading

[Jason Stubbs]

On Sunday 04 December 2005 11:08, Zac Medico wrote:
> Ned Ludd wrote:
> > With the size of the vdb effecting the speed of portage itself and with
> > all the desktop splitting up packages into massively large sets of many
> > ebuilds it's becoming apparent that that some optimizations need to be
> > done.
> >
> > strace -o woof -eopen -f python -c 'import portage'
> > grep '/var/db/pkg/sys-apps/portage-' woof
> >
> > You will notice that on a simple import that it's reading everything
> > twice. If anybody is up for the challenge of addressing this double
> > reading I think the entire user community would be thankful
> > (or atleast I would be)
>
> sandboxshell
> adddeny /var/db/pkg
> python -c 'import portage'
>
> From the resulting traceback(s), I was able to see that the /var/db/pkg
> reads originate in calls to a getvirtuals() method, which ultimately leads
> to a get_all_provides() method.  Assuming that the results from
> get_all_provides() do not change during the course of the initial 'import
> portage', it should be safe to cache the results (until the end of the
> import).

Following that through a bit further, get_all_provides() is only called by 
loadVirtuals() which is only called by config.__init__(). getvirtuals() 
itself is called outside of config.__init() once during initialization as 
well as by the scripts pkgmerge and repoman. In all three cases, the result 
is passed to portagetree.__init__(), binarytree.__init() or 
vartree.__init__(). However, none of those three classes use the passed 
virtuals anymore. Hence, all calls to getvirtuals() external to the config 
class could theoretically be dropped and replaced with an empty dictionary. 
The only possibility of breakage in doing that is if other parts of portage 
are accessing *tree's "virtual" member directly.

--
Jason Stubbs
-- 
gentoo-portage-dev@g.o mailing list