Gentoo Archives: gentoo-dev

From: Nick Jones <carpaski@××××××.net>
To: Yannick Koehler <yannick.koehler@××××××××.com>
Cc: gentoo-dev@g.o
Subject: Re: [gentoo-dev] Portage metadata
Date: Fri, 28 Feb 2003 07:55:34
Message-Id: 20030228013309.A15383@twobit.net
In Reply to: Re: [gentoo-dev] Portage metadata by Yannick Koehler
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