[devel] [PATCH 0/3] optimize rpmsetcmp()

[Alexey Tourbin]

On Sat, Dec 04, 2010 at 08:52:00PM +0300, Dmitry V. Levin wrote:
> On Sat, Dec 04, 2010 at 08:05:57PM +0300, Alexey Tourbin wrote:
> > On Sat, Dec 04, 2010 at 07:52:44PM +0300, Dmitry V. Levin wrote:
> > > > RPM goes reasonably fast, and it's not exactly "slower".
> > > > Something that might be called unreasonable is behind the RPM. 
> > > > 
> > > > I can't see why rpm is now 10x times slower.
> > > > Slower compared to... what?
> > > 
> > > You cannot dismiss arguments so freely.  The abovementioned command
> > > "apt-shell < /dev/null" from apt-0.5.15lorg2-alt33 works 10x times slower
> > > after update from librpm-4.0.4-alt98.45 to librpm-4.0.4-alt98.49.
> > > No matter how unreasonable apt is, it was rpm update that slowed it down.
> > 
> > Okay, what's the exact reason everything went 10x times slower?
> Huge amount of new set-versioned dependencies.

It's not exactly "huge", as it is predictably associated with the number
of shared libraries in use.  Also, I remember someone wondering about
"gosh, such a long version".  And he felt not that the library was
exporting too many symbols, though.  You see the pattern: the library
was okay.

There is indeed a considerable amount of new set-version dependencies.
And I never promised them to be a free lunch, or as cheap as strcmp().
Special compression routines (simplified Golomb-Rice encoding/decoding)
have been crafted to make set-versions shorter.  They are very cheap
(as compared to general-purpose compression routines such as found in
zlib), but they are still not free.

So the whole talk is that there's a price.  I believe that the price
is very affordable (or, at least, it could've been much worse).

Now as to apt misbehavior.  "You cannot dismiss arguments so freely."
What you urge to do is to cut down the price even more.  But there is
clearly something wrong with apt, as it tries to resolve every single
dependency upon every startup.  And, fortunately, it takes only a few
seconds!

> -- 
> ldv