Re: dpkg flex-based status file parser, for 35% speedup
Goswin von Brederlow writes ("Re: dpkg flex-based status file parser, for 35% speedup"):
> 35% speedup in 1% of the total time spend in dpkg? Is this the right
> place to optimize? I would have thought optimizing the *.list files
> would be more important. :)
It makes `dpkg --status <package>', `dpkg -l ...', etc. 35% faster.
It's true that it doesn't help much when you're doing a big
installation run but speeding up general queries is very worthwhile I
think.
> Ian Jackson <ian@davenant.greenend.org.uk> writes:
> > * It's about 25% smaller in source code, and I think much clearer.
>
> Thank you. That would be most welcome. On the other hand now the
> multiarch patches have to be rewritten.
I thought the most recent multiarch proposals didn't involve
substantial changes to the status and control file format ? I had
various conversations with people at Debconf about multiarch and found
it difficult to get hard information. Everyone I spoke to had
different ideas about what "the current plan" was and no-one was able
to point me to any definitive design documentation.
> > [...] It's tempting to say that we should merge dpkg
> > and dpkg-query and dpkg-trigger back into a single executable.
>
> Before you do that maybe it would be better to finaly create a libdpkg
> and put the common parts in there. A lot of dpkg functionality is also
> duplicated in apt and friends which is a real shame.
Making the common parts have a shape that's useful for apt et al is
nontrivial, unfortunately. Otherwise we would have had a useable
libdpkg already. This new parser is a step in that direction because
it makes it easier to reuse the meat of the parser separately from the
dpkg internal data structures (which have no stable ABI and are not
reentrant, to give the two clearest reasons why they're not suitable
for straightforward reuse).
I asked Wichert why he invented dpkg-query and apparently it was part
of an intended programme of modularisation. I think that's all well
and good but until we have effective code sharing arrangements we
should bundle it up back into one executable. So I will do that.
Ian.
Reply to: