On 19. 4. 2013 at 12:08:42, Panu Matilainen wrote: > On 04/18/2013 03:50 PM, Michael Schroeder wrote: > > On Thu, Apr 18, 2013 at 03:30:52PM +0300, Panu Matilainen wrote: > >> BTW there seems to be a bug in newrpmdb, related to the pkgidx/datidx > >> handling for the cases where ovldata is non-zero. It's masked by a > > > >> typo/thinko in the testit.c header data size calculation: > > Yes, the ent + idxdb->nslots * 8 is completely wrong. Fixing... > > Thanks, things are looking much better now. Quite good even, considering > what a quick and dirty hack the glue-code on rpm side is at the moment: > > My local newrpmdb test-branch can now do a full 'rpmdb --importdb', > perform installations and the test-suite is down to just two failures. > At least the other one is just missing glue-code to handle the the case > of "get all package id's from an index", the other one might well be > related to that too. > > I've only timed --importdb so far but amusingly enough, newrpmdb is > considerably faster there than BDB, even in the very rough and > non-optimal state of things. For my test-case of --importdb of 2197 > packages: > > For non-fsynced version (as is normally the case with --importdb): > newrpmdb: ~4.8s > bdb: ~7.7s > > When fsync is forced, newrpmdb took 2m 42s on one run. With BDB I ran > out of patience around nine minutes mark. Based on Packages size it was > somewhere around 60-70% at that point...
Impressive! Jan _______________________________________________ Rpm-maint mailing list [email protected] http://lists.rpm.org/mailman/listinfo/rpm-maint
