[Aptitude-devel] aptitude-qt VCS usage and code review

[Daniel Burrows]

On Fri, Jul 9, 2010 at 3:45 PM, Daniel Burrows <dburrows at google.com> wrote:
>> Getting numbers was much harder than I had thought. I was also not
>> sure what I should measure. I have decided to time creating list of
>> package objects with viewing and sorting by name on the list (only
>> name parameter is really used):
>>
>> 1) Fully eager
>>        2.75s
>> 2) Fully lazy (name and current version are loaded on creating package object):
>>        0.39s
>> 3) Memberwise lazy without caching:
>>        0.7s
>> 4) Memberwise lazy with caching:
>>        0.4
>
>   I think you said that this was for loading the whole package cache
> into a list, right?  So this is a worst-case estimate, and I think all of
> these are reasonable for the worst case (especially if you drop #1).

  Actually, could you humor me and run this with Package behind an
abstract virtual interface? (hiding the implementation in the .cc file)
I'd like to know what the cost would be.

  Long version: I don't like how tightly coupled aptitude is to apt.
Aside from the fact that it would cause trouble if I ever tried to switch
backends, it also makes it difficult to write automated tests for a lot
of the code (something that's frustrated me for a while now).  One
solution to this would be to hide apt behind an abstraction layer, which
would decouple aptitude from apt and make it easier to write tests
(by substituting fake implementations of the related interfaces).

  On the other hand, the PkgIterator objects are very efficient, since
most of their method calls are inlinable.  In the past, I've just assumed
that it wouldn't be reasonable to turn every call on a package into a
virtual method, but I have no evidence that this is actually true and
that I'm not just prematurely optimizing.  Also, it's not 1998 any more,
and both compilers and hardware have advanced a bit since then.

  Anyway, as long as you have the machinery set up for timing, I
thought it might be easy to get some numbers showing how costly
this would be in one particular instance.

  Daniel