[Qt-interest] QFileIconProvider "leaks" DLL's (qgifd4.dll, qicod4.dll, QtSvgd4.dll, etc.)
Thiago Macieira
thiago.macieira at trolltech.com
Thu Aug 20 12:31:34 CEST 2009
Em Quinta-feira 20 Agosto 2009, às 11:55:14, Niels Dekker - no return address
escreveu:
> Thiago Macieira wrote:
> > That's the low-level stuff. But there's no reference counting for each
> > image type. You can also note that Qt loads all the imageformat
> > plugins,
> > even if it just needs one of them.
>
> Do you mean that Qt could also improve its performance by loading only
> the plugins it really needs?
The problem is that it doesn't know which ones it needs. It needs to load them
all because the plugin decides if a given file is supported.
We can't make that decision before loading the plugins. Therefore, all are
loaded.
> > Should we load the plugins, read the image and then unload? So if you
> > have to read 200 images from a directory, should we load and unload
> > 200 times? Otherwise, how long should we keep the plugins? As long as
> > there's an image in memory?
>
> I think these are very good questions. It may be useful to have a
> mechanism to keep those plugins loaded while reading a bunch of images.
> But I think there should also be a way to unload the plugins, when the
> reading is done. Do you think the plugins should still be loaded when
> qApp is already destructed?
Maybe unloading on qApp shutdown is a solution. The problem then is that this
is not how the image plugins (or any other plugins, for that matter) are
implemented.
> >> I would find it disappointing if Qt would leak resources of our
> >> users, just to do some other users a very minor favor. Especially
> >> because there does not seem to be a workaround for us.
> >
> > I would too. Fortunately, there's no leak in this case.
>
> What do you mean, "there's no leak"???
There is no leak.
All memory that was allocated is still properly referenced. Repeating the
operation will not allocate more memory.
> We have an MFC application. While it's running, the user may choose to
> select a menu item to pop up a widget. Which loads "OurWidget.dll".
> Thereby, various Qt DLL's are loaded automatically. When the user
> closes the dialog, "OurWidget.dll" is unloaded. But most of the Qt DLL's
> remain loaded. Including the plugins and QtGui4.dll. Even when the user
> does not use anything based on Qt afterwards. Don't you think that's a
> leak?
No. There is no leak. If the widget is shown again, the same QtGui4.dll and
the plugins will be reused. They will not be loaded again. That characterises
a no-leak scenario.
You cannot expect the destruction of something to free all the resources that
it allocated on initialisation. There's such a thing as "allocate on first
use". It's similar to the Copy-on-Write principle that the memory manager uses
and Qt uses for the tool classes (implicit sharing). It's closer to the memory
manager's overcommitment feature: when you allocate a large block of memory,
you get a success, but the memory isn't really allocated until you try to use
it.
The alternative would be to acquire all of those resources on load, so that
they are released on unload. However, that would slow down the load process
for no good reason, since many resources would be loaded and initialised but
never used.
--
Thiago Macieira - thiago.macieira (AT) nokia.com
Senior Product Manager - Nokia, Qt Development Frameworks
Sandakerveien 116, NO-0402 Oslo, Norway
Qt Developer Days 2009 | Registration Now Open!
Munich, Germany: Oct 12 - 14 San Francisco, California: Nov 2 - 4
http://qt.nokia.com/qtdevdays2009
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.qt-project.org/pipermail/qt-interest-old/attachments/20090820/248991bf/attachment.bin
More information about the Qt-interest-old
mailing list