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

[Daniel Burrows]

On Fri, Jul 9, 2010 at 2:38 PM, Piotr Galiszewski <piotr at galiszewski.pl> 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).

> My laptops has quite modern processor (c2d T 9400 (2x2.5) and 4 GB of
> ram). On slower computers the difference will be greater.So it looks
> like the caching gives some nice improvements. I do not have any
> numbers, but I think that option number 4 will be even better than
> option 2. With option number 2 first searching by description is quite
> long. Probably time is similar to measured Fully eager time. Option 4
> probably will be easier to implement. Most of the variables are
> strings so one simple if with  empty() option should work. Current
> behaviour of Qt frontend is little problematic, cause ensure_loaded
> discards const qualifier of getters.. In 4 mutable should work

  I could probably slap together a template to make this a lot simpler,
too.

> So, what are you proposing as my next task? :)

  I'll try to review some of your patches later today, which should give
you somewhere to start.

> I have to learn more about boost :)

  Boost is cool.  Just be careful which parts you use -- it's not all written
to the same standard.  multi_index is one of my favorite container
libraries, but flyweight has a major bug that makes it unsuitable for
most interesting applications -- sadly, since it would be perfect for your
package objects. :-(   (the bug is that you have to make sure that every
flyweight of a particular type is destroyed before you invoke exit(), or
the program will die with an assertion error)

> >   In the GTK+ and curses frontends, we deal with the cache being
> > reloaded by throwing away all the currently displayed packages
> > and rebuilding the view from scratch.  The only real alternative would
> > be to somehow merge the new cache into the display, maybe on the
> > basis of name and/or version strings?  I don't think it's worth the
> > trouble for your first version.
>
> That was also my plan. My only concern is about earlier opened
> package_info tabs. They also contain reference to package object, so
> they should be updated. But probably it is not big problem, cause I
> could identify them also by name

  Yes, that's exactly what's done.  We store the package name and version
string and try to relocate it.  I forget what happens if the version can't be
found -- hopefully something sensible!

  Daniel