* Stephen John Smoogen:
On 11 July 2017 at 16:48, Florian Weimer <fw(a)deneb.enyo.de>
wrote:
> * Stephen John Smoogen:
>
>> On 11 July 2017 at 07:52, Michael Schroeder <mls(a)suse.de> 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).