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 -
_______________________________________________
Yum-devel mailing list
[EMAIL PROTECTED]
https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
