Re: dpkg speed (was: Re: PROPOSAL: Extrafiles)
Martin Schulze <firstname.lastname@example.org> writes:
> On Thu, Jun 04, 1998 at 01:44:05PM -0400, Christian Hudon wrote:
> > If I understand correctly, the thing that slows down dpkg's startup the
> > most is reading those bazillion .list files. 'available' alone probably
> > isn't a very representative test.
> According to Ian Jackson yesterday or the day before, dpkg
> spends most of its time reading and managing all the description
> for the packages. He also admitted that this could be improved
> in speed... to be done by... you? Go ahead, send a patch, please.
I don't even have source for current dpkg:) I only made simple (~300
lines) test program to read 'available'. It finds every tag (Package,
Installed-Size, ...) for every package and qsorts packages. After
sort most operations should be fast. It should have enough error
checking. It probably could be used in dpkg or in dselect with few
small modifications (data structure). I could mail it to anyone who
wants to test it.
Of course reading many small *.list files is very slow. New format
is only possibility to speed it. File size becomes large (=slow), so
some kind of compressed/binary format is needed. (I failed to find
Jason Gunthorpe's proposal for new format.)
Also 'Depends' lines in available could cause a problem. When
removing a package, it is necessary to scan all installed packages to
find dependencies (at least i believe so:). This is rather slow.
Simplifying 'Depends' line format would help ('|' is unnecessary
because 'Provides' could be used instead.)
Does any program scan available:
for every package X in available
find all packages which depends on X.
I did not find simple (= fast) way of doing it.
Is there anything else time consuming dpkg needs to do?
To UNSUBSCRIBE, email to email@example.com
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org