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

[Daniel Burrows]

On Thu, Jul 8, 2010 at 5:25 PM, Piotr Galiszewski <piotr at galiszewski.pl>wrote:
>
> Great ;) . I have already learned a lot and I know that every
> experiences are important. I was only little nervous about gsoc
> timelines, cause I am far behind my original schedule :/
>

  Well, from my (selfish) point of view, I'd rather have you focus on
quality over quantity.  That's because if you write good code, even
a small amount, I can use it.  If you churn out a ton of code that's
not up to snuff, it'll probably just end up being dropped and the
whole exercise will be a waste of time for both of us.


> >   Is package_manager some sort of a global storage pool of Packages,
> > then?  Could you maybe call it package_pool instead to avoid naming
> > confusion?
>
> yes it is. I will call it that
>
> >   I don't really understand the whole purpose of the Package object.
> > Is the goal here to save memory and CPU time by only copying package
> > information into QStrings once per package?
> >
>
> For model I need an array of packages. And as the number of packages
> is really big I have decided that custom class with lazy loading could
> be a good idea. And my tests show that it is true (especially in case
> of showing description on the list)


  The other frontends don't have to do this, or perhaps they just are
slow and could benefit from your work here!  Either way, I'd like to dig
into
this a little more.

  These are the ways of retrieving package information from a package
that spring to mind immediately:

  1) Fully eager: as soon as the Package is created, copy all the values
from
      the PkgIterator over into the Package object (I believe the GTK+ code
      effectively does this).
  2) Fully lazy: the first time a member of Package is accessed, copy all
the
      values from the PkgIterator into it (what the current Qt code does).
  3) Memberwise lazy without caching: just store a PkgIterator; when a
      component of the Package is requested, return the corresponding
      member of the PkgIterator (what the curses frontend does).
  4) Memberwise lazy with caching: when a component of the Package is
      requested, copy the corresponding member of the PkgIterator into the
      Package object and return it (I don't think any aptitude code does
this).

  Which of these did you try?  Do you have numbers showing how big an
improvement you saw?  Could you try some of the others to compare?

  Is there any way to lose the QFoo types in Package?  I'm not sure we
want to reuse it directly, but there might be a way to solve this problem
more generally, as long as it doesn't require the use of Qt-specific (or
GTK-specific) types.

  Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/aptitude-devel/attachments/20100708/4efabc9a/attachment.htm>