Re: dpkg speed (was: Re: PROPOSAL: Extrafiles)
On Mon, 1 Jun 1998, Anthony Towns wrote:
> [please direct followups appropriately, this digression doesn't really
> belong on -policy]
>
> On Sun, May 31, 1998 at 09:26:38PM -0700, Karl M. Hegbloom wrote:
> > >>>>> "Anthony" == Anthony Towns <aj@azure.humbug.org.au> writes:
> > Anthony> (as it stands, things like `dpkg --search /etc/passwd'
> > Anthony> results in `dpkg: /etc/passwd not found.' Personally I
> > Anthony> consider this alone a little disconcerting)
> > ... and it takes forever and a day of disk ggzztting to give you the
> > result too. I will be glad when the contents of some future and
> > quick database have been worked out, and that database gets built.
> > `dpkg' could be as fast as `rpm' then.
>
> I'm personally against moving towards a heavily optimised databasey
> format, for the simple reason that I like being able to get at stuff
> with less and grep.
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.
> There are a couple of things which might be worth considering though.
> In particular, I suspect pre-sorting [0] all the .list and .conffiles,
> and using a binary-search for dpkg --search (and probably a different
> data structure when doing other operations (a binary tree, built to be
> balanced, with additions as necessary, perhaps?)) would go a fair way to
> tidying it up. I suspect splitting dpkg/info into subdirectories would
> do some good to.
Yes, these are good ideas.
> Has anything along these lines already been done in the experimental
> dpkg, btw?
I don't know. If I had the knowledge required to modify dpkg I would try
and find time for it, but I'm afraid all I can do is tell you how I'd like
it to be.
Remco
--
To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: