| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
|
| 5 |
> The basic problem in searching is actually that it isn't implemented |
| 6 |
> smartly |
| 7 |
> in current portage. I have working (emerge -s like) code that is |
| 8 |
> blazingly |
| 9 |
> fast as it does not actually open all ebuilds. |
| 10 |
Searching works off of the cache for the most part, if a cache entry is |
| 11 |
stale, it's updated (eg the ebuild is opened and srced). |
| 12 |
Unless you're not checking the cache and updating it as you proceed, |
| 13 |
you're implementation ought to suffer the same limitation. |
| 14 |
|
| 15 |
> Doing description searching is |
| 16 |
> impossible to do fast without some kind of cache. I don't think |
| 17 |
> creating a |
| 18 |
> reliable cache for that is going to be a priority, |
| 19 |
There are 2 things that need to be done (in my books at least) to step |
| 20 |
up the speed of a description search- |
| 21 |
A) sql based cache backend, whether sqlite or mysql. Either that, or |
| 22 |
extend the flat cache to store the descriptions in a central index. |
| 23 |
B) alter the search description alg so that instead of stepping through |
| 24 |
each entry getting the description, we just state "give me all packages |
| 25 |
that have a description matching blar", and leave it up to the backend |
| 26 |
to decide what is the most efficient way to search. With flat cache, |
| 27 |
we'd still have to go file by file; w/ a sql variant, it could take |
| 28 |
advantage of the appropriate syntax. |
| 29 |
|
| 30 |
Since there is code for a sql based cache backend, B has been bounced |
| 31 |
around in #gentoo-portage a bit. Prior to it actually happening I |
| 32 |
would think the sql db code would need to be cleaned up/QA'd/etc. |
| 33 |
|
| 34 |
Course, there still is the issue of verifying that the cache entry |
| 35 |
isn't stale... :) |
| 36 |
|
| 37 |
> We need something |
| 38 |
> that works in such a way that even a corrupted tree gets into a good |
| 39 |
> status |
| 40 |
> after updating. |
| 41 |
Err, eh? If the tree is corrupted, and sync'd against a |
| 42 |
good/non-corrupted tree, it ought to be reverted to a sane state. |
| 43 |
|
| 44 |
~brian |
| 45 |
-----BEGIN PGP SIGNATURE----- |
| 46 |
Version: GnuPG v1.2.4 (Darwin) |
| 47 |
|
| 48 |
iD8DBQFBBYxevdBxRoA3VU0RApzhAKDBI59X1EcaKA0SdjjuoXvLx98ndQCeOKFi |
| 49 |
zoCzNhViFLuZObVorDRvggU= |
| 50 |
=GWOF |
| 51 |
-----END PGP SIGNATURE----- |
| 52 |
|
| 53 |
|
| 54 |
-- |
| 55 |
gentoo-performance@g.o mailing list |
Archives