[Yum-devel] Current yum git desolver is a little slow

seth vidal skvidal at fedoraproject.org
Wed Aug 22 16:52:23 UTC 2007


On Wed, 2007-08-22 at 16:08 +0200, Tim Lauridsen wrote:
> Florian Festi wrote:
> > Tim Lauridsen wrote:
> >> I did some basic testing of the current yum git HEAD vs. yum 3.2.2.
> >
> > Yes, current git head is a bit slower than 3.2.2. There is a simple 
> > reason for that: Linear searches on disk are even slower than linear 
> > searches in memory.
> >
> > In other words: We are still missing some indexes in the sqlite 
> > database to really gain speed from the changes. For performance runs 
> > you can temporary remove patch 
> > 3c2621ba8f8070f24ad3e979f6bd1699f6f6b394 or readd 
> > 42283902f929ac131cda7b3497ae047b497e02bc.
> >
> > There are two possible permanent solutions:
> >
> > Readd the patch mentions above and extend it that all indexes are 
> > created if they are not present yet. I posted timings for creating 
> > these indexes some weeks ago (2. Aug "Sqlite DB Indexes").
> >
> > As alternative or in addition we could patch yum-metadata-parser to 
> > just add the needed indexes.
> >
> > I can provide patches for both as soon as there is a decision with 
> > way(s) we want to go.
> >
> >
> I added this
> http://devel.linux.duke.edu/gitweb/?p=yum.git;a=commitdiff;h=42283902f929ac131cda7b3497ae047b497e02bc
> It speed up things a lot, but makes yum load the metadata every time, 
> because the index creation changes the checksum i think.
> I we want to create the indexes locally, how do we know when to download 
> the sqlite tarball from the repo ?
> 

I don't think we want to make them locally. For verification purposes
it's a dicey proposition.

Think about this:

if we see that the sqlite file is changed - how do we know it was
changed due to index generation and not due to someone mucking with our
metadata?

-sv





More information about the Yum-devel mailing list