[Aptitude-devel] Experimental package and package_pool implementation

[Piotr Galiszewski]

2010/7/16 Daniel Burrows <dburrows at debian.org>:
> On Thu, Jul 15, 2010 at 09:19:48PM +0200, Piotr Galiszewski <piotr at galiszewski.pl> was heard to say:
>> 2010/7/15 Daniel Burrows <dburrows at google.com>:
>> > On Thu, Jul 15, 2010 at 10:05 AM, Piotr Galiszewski
>> > <piotr at galiszewski.pl> wrote:
>> >> Today I have rebased my later patches to current code. Unfortunately
>> >> there is one big problem with package_pool. Creating package list
>> >> takes nearly 17 seconds on my machine. The problem is with
>> >> boost::multi_index_container. I have changed this to std::vector and
>> >> time is 0.3s now.
>> >
>> >  Interesting, I'd like to know why that is so we can avoid hitting it again.
>> > Glad it's fixed, anyway.
>> >
>>
>> I have no idea. Maybe it was caused by not used hashed_unique?
>
>  So, I saw you branched the broken code, but I'm not sure how to test it?
> (--qt does nothing)
>

I have forgotten that this part of code is not used anywhere. Apt
initialization is also missed. I will rebase this branch and will add
code I used to get numbers. It is primitive but works ;)

>  Anyway, my two theories are:
>
>    1) I wonder how it was hashing PkgIterators in your hashed_unique
>       matcher.  The only hash I can find on package iterators doesn't
>       use the boost::hash framework and isn't used anywhere.
>
>       If it was falling back to some default hash that gave them all
>       the same hash value, this could explain your performance
>       problems.  (although the only way I can think of for them to
>       be hashed is via conversion to Package*, which should work)
>

Probably that is it. I have not thought about this when writing code.
With vector it works nice. If it will be necessary to come back to
multi_index, I know now what should be done. Thanks

>    2) I didn't think to suggest reserving space in the unordered index
>       as well.  I don't think that explains nearly two orders of
>       magnitude in performance loss, though.
>
>  Daniel
>
> _______________________________________________
> Aptitude-devel mailing list
> Aptitude-devel at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/aptitude-devel
>



-- 
Regards
Piotr Galiszewski