On Tue, Mar 14, 2006 at 04:33:06PM +0200, tvali wrote:
> I did think about it now and it seems to me that probably it would be
> much faster if esearch is not just another package, but part of
> portage.
> I mean -- functions of portage, which query db, should use esearch
> index wherever they need information, which exists in that index.
> As much as i can understand, /var/cache/edb/ contains esearch database
> in many files and esearchdb.py is search index as python script.

esearch is a static db- only useful for 'frozen' trees, eg rsync 
distributed trees with no eclasses in overlays.  All cvs users (devs) 
run unfrozen trees (readonly/readwrite is better terminology), thus 
portage updates the cache db on the fly as needed.

If esearch was integrated into portage the result would be stale 
metadata for cvs users, and stale metadata for rsync users when 
overlays with eclasses are involved- no go.

That and esearch last I looked just generates a giant dict (thus the 
cache is in memory), which kind of blows the <25mb mem usage 2.1 
now sports :)


Attachment: pgpjlCAV4I3Za.pgp
Description: PGP signature

Reply via email to