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)
The time it takes to import portage with only 78 pkgs installed takes
about 1 second. On the same box in another chroot it takes over 4-5
seconds with about 400 packages installed. I hear of some guys that have
over 1000 packages installed. That must be a nightmare especially with
packages that make heavy use of the portageq command.
Well, we all know that the second read is quicker than the first due to kernel
caching. ;)
But anyway, out of curiousity, I did the following:
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).
Zac
--
[email protected] mailing list
