Re: [gentoo-portage-dev] portage-2.0.51_rc1 intermittent slowdowns

[Brian]

On Sat, 2004-09-25 at 20:49, Jason Stubbs wrote:

> There is a cache format change between 2.0.50 and 2.0.51. The slowdowns are
> due to portage doing just-in-time rebuilding of the cache. The first emerge
> sync or emerge metadata after an upgrade to portage-2.0.51 will clear it up
> altogether.
>
Yes, that has cleared.

> Regards,
> Jason Stubbs
>

I hace _rc3 installed now.  I have found one other area that has taken a
performance hit with the new portage

porthole code fragment:

def read_db(self):
    """Read portage's database and store it nicely"""
    tree = portage.db['/']['porttree']
    self.get_installed()
    try:
        dprint("PORTAGELIB: read_db(); getting allnodes package list")
        allnodes = tree.getallnodes()
        dprint("PORTAGELIB: read_db(); Done getting package list")
    except OSError, e:


[/code]

The  getallnodes() now takes 2 to 8 times longer to complete.  It showed
up as a very noticeable lag before the data loading progress bar showed
any change from 0%.  That getallnodes portion of the code was not taken
into consideration for the percent calculation before as it was not an
time issue.  Re-instating some debug staements I was able to pinpoint
the lag.   The getallnodes portion was about 5 to 15 gtk timeout cycles
(about 25-30% of total time) for the thread monitoring function and is
now 
taking 35 to 60 timeout cycles (50-70% of total time).

Is there perhaps a better way to get this info with the new portage
untill the portage API is integrated?

-- 
Brian <dol-sen@×××××.net>


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