Re: dpkg speed (was: Re: PROPOSAL: Extrafiles)
Remco Blaakmeer <email@example.com> writes:
> That's why I and several other people have proposed a cache database. The
> text files will still be the authoritative source of information for dpkg.
> But after dpkg has read them and built its database in memory (as it does
> now), it can save this database to disk. The next time dpkg runs, it can
> simply stat the text files and the database and then use either the text
> files or the cache database, depending on which has been modified more
> recently. And every time dpkg updates the database from a Packages
> file, it will write not only the updated database but also the updated
> text files to disk.
> If I am correct, this means that dpkg only needs to rebuild the database
> from scratch if the sysadmin has edited one or more of the text files.
> This could mean a much shorter startup time for dpkg.
How fast does it have to be? I made a test program to read
/var/lib/dpkg/available. (1181637 bytes, 1882 packages)
Test run in 486 DX2 66 with bigfoot disk:
read : User: 0.0300 s System: 0.6500 s Real: 0.8700 s
parse: User: 0.2900 s System: 0.0000 s Real: 0.2900 s
sort : User: 0.1800 s System: 0.0000 s Real: 0.1800 s
write: User: 0.4100 s System: 0.1500 s Real: 0.6300 s
total: User: 0.9200 s System: 0.8000 s Real: 1.9800 s
output of '/usr/bin/time -v':
User time (seconds): 0.94
System time (seconds): 0.81
Percent of CPU this job got: 85%
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:02.04
'read' reads /var/lib/dpkg/available 'write' writes sorted file in
'sort' sorts package descriptions using 'Package: ' line as a sort
key. It is single qsort() call. Any other line could also be used as
a sort key.
'available' seems to be too sort file to time this accurately.
'available in binary format could be slightly smaller. So read and
write times could be slightly shorter. Parse and sort would not be
needed. Since disk io takes most of the time, even in 486, binary
format is not very useful.
To UNSUBSCRIBE, email to firstname.lastname@example.org
with a subject of "unsubscribe". Trouble? Contact email@example.com