Re: dpkg flex-based status file parser, for 35% speedup
Hi,
On Thu, 2007-08-30 at 12:09:22 +0100, Ian Jackson wrote:
> 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.
Yes, this is really nice.
> > Ian Jackson <ian@davenant.greenend.org.uk> writes:
> > > * It's about 25% smaller in source code, and I think much clearer.
> > > [...] 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.
> 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.
I don't see the point in merging it back, to have to undo that later
on. I think it's way better if we use this as an excuse to actually
start moving towards a proper libdpkg, we might have to start some
day anyway.
I've just prepared a patch which switches the library to be shared
one (I'm missing adding a version script), for now we'd only provide
libdpkg0 (and probably libdpkg0-dbg), and no libdpkg-dev, as the lib
should be considered private as it is now.
At the same time this rises the question of the static linking
against zlib, libbz2 and libselinux, I've switched those to dynamic
linking in the patch, as I don't think the current situation makes
much sense. We'd need PIC versions otherwise, it's a pain for security
reasons (#317967), if the system gets into a state that dynamic linking
does not work, you have probably worse problems than dpkg not working,
and we rely on other essential packages linking against some of these
libs (zlib and libselinux). Also the addition of libbz2 as
pseudo-essential should not be a big deal, it's quite small, and most
of the code is duped already due to it being statically linked.
So I would upload the current version and delay the switch until next
release, probably with a version to experimental so that we don't get
locked in NEW.
regards,
guillem
Reply to: