[Aptitude-devel] Experimental package and package_pool implementation

Daniel Burrows dburrows at google.com
Mon Jul 12 23:17:05 UTC 2010


On Mon, Jul 12, 2010 at 3:30 PM, Sune Vuorela <nospam at vuorela.dk> wrote:
> On 2010-07-12, Daniel Burrows <dburrows at google.com> wrote:
>>     - I would drop the virtual destructor here and make it impossible to
>>       subclass package (by hiding its constructor and using a static factory).
>>       That allows you to avoid a virtual method table for each instance (not
>>       a huge deal even if we create tens of thousands of them, but not bad
>>       either)
>
> I think that constantly converting to and from Qt types is going to be a
> bigger performance killer than most other things in this code, so I
> really think we should do as few conversions as possible to and from Qt
> types. This means, use the QFoo in as many cases as possible.

  I think this package code will eventually be generally useful, so I want to
make sure we don't make it Qt-specific unless it's really necessary.  I also
don't think it'll be too expensive to do the conversions, as long as we only
convert on an as-needed basis (rather than converting the whole world up
front).


  Here's another way of looknig at it it: there's a GFoo string, Glib::ustring.
When you search for a bunch of packages in the GTK+ frontend, it retrieves
all their information and copies it into new Glib::ustring objects.
(see fill_row
in pkgview.cc)  The GTK+ interface seems to be fast enough despite these
unnecessary copies, and I think Piotr's design is already going to copy less
than the GTK+ code does.

  Daniel



More information about the Aptitude-devel mailing list