[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