Comment 8 for bug 635834

I did not mean to imply you have done --rebuilddb benchchmarks. My statement is
true no matter what: neither -qa _NOR_ --rebuilddb are proper measurements
of rpmdb "performance" because the access is sequential. So any claim of "inefficient"
rpmdb I/O will only apply narrowly and incompletely.

> Is this rpm 4.7 going to be replaced by rpm 5 - or is it unrelated project to
> Fedora's rpm package?

I quote myself "irrelevant". The problems were the same as what is in your callgrind
spewage because the code was largely the same. But feel free to not look for fixes
in projects that are unrelated to Fedora. The measured callgrind speed up after fixing
dataLength and other issues was 14.6x @rpm5.org.

> As I've said - callgrind will not show I/O stalls.

Yes. Which is why I use callgrind to measure I/O "overhead" claims as here.

> Do you flush disk buffers within your tests ?
Callgrind measurements are largely immune to buffer state as well. Yes I flush buffers
where needed or appropriate.

Are you claiming I/O stalls or not? You have not disclosed any measurement
that directly shows stalls, only pointed out the possibility afaict. strace tstamps
would be convincing. I have not seen stalls, or behavior indicative of I/O waits,
while benchmarking RPM.

> Yeah - sure python is much bigger CPU eater in this case - but rpm is not
> negligible either...
LVM is not exactly svelte either. Reasoning from yum->python->lvm peformance
to claimed "inefficient database disk reading" for RPM based on the largeness
of the code base is no measurement I understand.