| 1 |
On Tue, Mar 14, 2006 at 04:33:06PM +0200, tvali wrote: |
| 2 |
> I did think about it now and it seems to me that probably it would be |
| 3 |
> much faster if esearch is not just another package, but part of |
| 4 |
> portage. |
| 5 |
> |
| 6 |
> I mean -- functions of portage, which query db, should use esearch |
| 7 |
> index wherever they need information, which exists in that index. |
| 8 |
> |
| 9 |
> As much as i can understand, /var/cache/edb/ contains esearch database |
| 10 |
> in many files and esearchdb.py is search index as python script. |
| 11 |
|
| 12 |
No... |
| 13 |
esearch is a static db- only useful for 'frozen' trees, eg rsync |
| 14 |
distributed trees with no eclasses in overlays. All cvs users (devs) |
| 15 |
run unfrozen trees (readonly/readwrite is better terminology), thus |
| 16 |
portage updates the cache db on the fly as needed. |
| 17 |
|
| 18 |
If esearch was integrated into portage the result would be stale |
| 19 |
metadata for cvs users, and stale metadata for rsync users when |
| 20 |
overlays with eclasses are involved- no go. |
| 21 |
|
| 22 |
That and esearch last I looked just generates a giant dict (thus the |
| 23 |
cache is in memory), which kind of blows the <25mb mem usage 2.1 |
| 24 |
now sports :) |
| 25 |
|
| 26 |
~harring |
Archives