[Rpm-maint] [PATCH] rpmdbCountPackagesArch

[Pixel]

Thomas Fitzsimmons <fitzsim at redhat.com> writes:

[...]

>> In the typical case, rpmtsRun() is already doing 2 iterations on
>> "Name" doing headerLoad. And there are a few more.
>>
>> IMO if we look at optimisations, there are many things that should be
>> done before this. For example, it would be far more effective to
>> introduce a "Packages-light" with only the more interesting piece of
>> information (EVRA and maybe a few more). This would make "rpm -qa"
>> much much more faster/lighter (I/O accesses on Packages are really
>> killing it).
>>
>> So i would say, implement rpmdbCountPackagesArch() using
>> rpmdbSetIteratorRE() for now.
>
> I've attached tests that benchmark name-only lookups versus
> rpmdbSetIteratorRE-based name-arch lookups.  On my Fedora 9 32-bit x86
> machine:
>
> [...]
>
> So over many transactions, using rpmdbSetIteratorRE is much slower
> than using the Namearch index.

sure it's much slower. 

But afaik this rpmdbCountPackagesArch() is to be used for scriptlets.
So my question is how much slower it is in a package install. I would
say it is barely noticeable.

i've tried adding the "slow" rpmdbCountPackagesArch() in transaction.c
after the RPMPROB_FILTER_OLDPACKAGE and RPMPROB_FILTER_REPLACEPKG
checks.

i get:

*** time 534 usecs (checking a newer version is not installed)
*** time 169 usecs (checking a same version is not installed)
*** time 148 usecs (counting same arch)

ie the first one is quite costly, then it's quite the same.

i could not see the speed difference with or without the added
rpmdbCountPackagesArch() call.

(nb, test was: installing pkg "a-3" where "a-1" and "a-2" are installed)


>      rpmdbSetIteratorRE (mi, RPMTAG_ARCH, RPMMIRE_DEFAULT, "i686");

RPMMIRE_DEFAULT is "regex with \., .* and ^...$ added"
using RPMMIRE_STRCMP instead gives you back 25% speed.