1 |
>> 2. For later speedups, is anybody looking into using actual database |
2 |
>> formats for the data? (GDBM/BDB/NDBM/etc.) |
3 |
> |
4 |
> Python internal DB is cache in memory and is quite fast, for certain task a DB |
5 |
> would be faster but most of the time, the python DB seems to kick ass unless |
6 |
> you do description search. |
7 |
|
8 |
Used a 2.0.47-series? ~20-60 seconds depending on your box. That |
9 |
includes printing all the descriptions, checking versions, etc. |
10 |
|
11 |
This of course assumes you're using an rsync via 'emerge sync' and |
12 |
you aren't anhiliating/damaging /var/cache/edb/dep in some fashion. |
13 |
|
14 |
> |
15 |
> I have written in the past a bash script that generated an XML files out of |
16 |
> the /var/db/pkg. If you can import that 4 Megs files inside a DB then you |
17 |
> could run some query and time them and see how things get faster. |
18 |
|
19 |
Databases are not going to be that great of a speedup as it incurs the |
20 |
overhead of the DB. Portage's DB is an on-demand one-file-per-ebuild |
21 |
cache that is trivial to parse as it's one line per field. Ensuring |
22 |
that the db is proper would take just as long, if not longer, than using |
23 |
the server side cache (metadata/cache) as 'emerge sync' does already. |
24 |
|
25 |
--NJ |
26 |
|
27 |
-- |
28 |
gentoo-dev@g.o mailing list |