* Stephen John Smoogen: > On 11 July 2017 at 16:48, Florian Weimer <fw@xxxxxxxxxxxxx> wrote: >> * Stephen John Smoogen: >> >>> On 11 July 2017 at 07:52, Michael Schroeder <mls@xxxxxxx> wrote: >>>> On Tue, Jul 11, 2017 at 06:41:05AM -0400, Neal Gompa wrote: >>>>> And we do use SQLite today in DNF with the yumdb, as well as the new >>>>> SWDB coming soon(TM). I'm not sure why the SQLite backend was removed >>>>> in rpm 4.9.0, but maybe it should be revisited for rpm 4.14. >>>> >>>> AFAIR it was removed because it was unbearable slow, nobody used it, >>>> and nobody wanted to maintain it. >>>> >>> >>> 1. It was very slow.. and developers complained a lot about how long >>> it took to get various things done. >> >> It looks like the backend was ported from SQLite 2 code initially. >> The result set processing code indeed loks quite inefficient (result >> set cells are are allocated individually, memcpy is used to copy an >> int, and so on). But I'm still surprised this was observable to >> users. > > Never doubt the amount a developer will complain when either an > install or build takes longer than it did before. Especially when they > have to do dozens or hundreds of builds. In mock? Yes, that (and installation in general) look rather slow because *every key lookup* appears to be wrapped in a getcwd/chroot/chdir/chroot sequence. It looks like this was implemented to fix this bug: <https://bugzilla.redhat.com/show_bug.cgi?id=159424> Unfortunately, the bug doesn't say why the fix took this particular form (and why the database wasn't always opened outside of the chroot instead). _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
