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

[Piotr Galiszewski]

2010/7/10 Daniel Burrows <dburrows at google.com>:
> 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.
>

Yes, sure. the results are below

>  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.
>

I rerun my previous tests, cause I have already change and remove
previous tests (I had a lot of fun with git after rebasing my first
patch ;) ). Here are new results (I have no idea, why they are
slightly different than yesterday's)

1) Fully eager
       2.35s
2) Fully lazy (name and current version are loaded on creating package object):
       0.27s
3) Memberwise lazy without caching:
       0.535s
4) Memberwise lazy with caching:
       0.255

I have created ipackage interface and package class delivers from
this. I have also change other required code. There were no visible
difference from the above results. Accuracy of my measurement is not
sufficient in this this case (but as I said I tested it on quite
modern cpu)

>  Daniel
>
-- 
Regards
Piotr Galiszewski