[Yum-devel] [RFC] dbversion 10

[Panu Matilainen]

On Wed, 11 Apr 2007, James Bowes wrote:

> Panu Matilainen wrote:
>> It's not just about breaking yum API but also about any other repodata
>> sqlite users. The only one at the moment is probably apt-rpm and even
>> there it's not included in any released version yet so from that POV
>> now's a good time to make changes (even bigger ones if needed), later it
>> gets a bit uglier. Although I will need to figure out a nice way to
>> support more than one db format sooner or later by looks of things.
>
> Just out of curiosity, how much faster is it for you to read from the db
> and convert to apt's cache format than it was to work with the xml?

In the current git-version rather unoptimized implementation, the speed is 
very similar for xml vs sqlite with xml being slightly faster but using 
something like four times more memory. The memory overhead of xml could be 
largely avoided but haven't gotten around to break a working 
implementation, especially with this sqlite-stuff coming to existence.

The immediate win in sqlite for apt has to do with hysterical apt 
internal assumptions: it assumes that opening a package index file and 
looking up a package within it is as cheap as open() + seek(). Now, 
obviously that's NOT the case with large XML files such as in repodata. 
Because of that and various other nutty internal issues, with xml repodata 
it's actually faster for apt to do a full distro version upgrade depsolve 
than to calculate how much needs to be downloaded... go figure :) In case 
of sqlite, the opening of package index and seeking to a location is very 
fast, eliminating that problem without requiring changes to the other 
internals.

 	- Panu -