Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-performance
Navigation:
Lists: gentoo-performance: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-performance@g.o
From: Brian Harring <ferringb@g.o>
Subject: Re: Re: portage performance
Date: Mon, 26 Jul 2004 17:57:28 -0500
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> The basic problem in searching is actually that it isn't implemented 
> smartly
> in current portage. I have working (emerge -s like) code that is 
> blazingly
> fast as it does not actually open all ebuilds.
Searching works off of the cache for the most part, if a cache entry is 
stale, it's updated (eg the ebuild is opened and srced).
Unless you're not checking the cache and updating it as you proceed, 
you're implementation ought to suffer the same limitation.

>  Doing description searching is
> impossible to do fast without some kind of cache. I don't think 
> creating a
> reliable cache for that is going to be a priority,
There are 2 things that need to be done (in my books at least) to step 
up the speed of a description search-
A) sql based cache backend, whether sqlite or mysql.  Either that, or 
extend the flat cache to store the descriptions in a central index.
B) alter the search description alg so that instead of stepping through 
each entry getting the description, we just state "give me all packages 
that have a description matching blar", and leave it up to the backend 
to decide what is the most efficient way to search.  With flat cache, 
we'd still have to go file by file; w/ a sql variant, it could take 
advantage of the appropriate syntax.

Since there is code for a sql based cache backend, B has been bounced 
around in #gentoo-portage a bit.  Prior to it actually happening I 
would think the sql db code would need to be cleaned up/QA'd/etc.

Course, there still is the issue of verifying that the cache entry 
isn't stale... :)

> We need something
> that works in such a way that even a corrupted tree gets into a good 
> status
> after updating.
Err, eh?  If the tree is corrupted, and sync'd against a 
good/non-corrupted tree, it ought to be reverted to a sane state.

~brian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFBBYxevdBxRoA3VU0RApzhAKDBI59X1EcaKA0SdjjuoXvLx98ndQCeOKFi
zoCzNhViFLuZObVorDRvggU=
=GWOF
-----END PGP SIGNATURE-----


--
gentoo-performance@g.o mailing list

Replies:
Re: Re: portage performance
-- Paul de Vrieze
Re: Re: portage performance
-- Jesse Guardiani
References:
portage performance
-- Jesse Guardiani
Re: portage performance
-- Jerry McBride
Re: portage performance
-- Jesse Guardiani
Re: Re: portage performance
-- Bart Alewijnse
Re: Re: portage performance
-- Paul de Vrieze
Navigation:
Lists: gentoo-performance: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: Re: portage performance
Next by thread:
Re: Re: portage performance
Previous by date:
Re: Re: portage performance
Next by date:
Re: Re: portage performance


Updated Jun 17, 2009

Summary: Archive of the gentoo-performance mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.