[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