[Qt-interest] QFileIconProvider "leaks" DLL's (qgifd4.dll, qicod4.dll, QtSvgd4.dll, etc.)

[Thiago Macieira]

Niels Dekker - no return address wrote:
>Loading plugins for the first time may be expensive, but I wonder if
>re-loading those plugins a second time is still expensive. For example
>on Microsoft Windows, a second call to LoadLibrary for the same DLL is
>much faster than the first one.  Even if you have unloaded the DLL,
>between the LoadLibrary calls.  Because the OS typically still has the
>DLL is cache.

Cache isn't enough. There are relocations to take care of, so it's 
definitely more expensive than keeping it loaded.

>Note also that both Windows and Linux use a reference-counting mechanism
>to keep a dynamic library loaded as long as at least one component still
>has the library in use. Both FreeLibrary (Windows) and dlclose
>(Linux/Unix) just decrement the reference count of the specified
>library, and only unload when the count is zero.

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.

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?

What happens about the pixmap cache? Remember that parsing images is also 
expensive, so keeping them in pixmap format is also useful. So it happens 
very often that there are images in cache because you've used them often.

Icons are a very good example of cached images.

>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.

If you're referring to the plugins being loaded in memory, I would argue 
the other way around: I would be very much against worsening the 
performance of our users just to do some few users a very minor favour.

>> Qt image plugins aren't expected to change, so we
>> never unload them either.
>
>Does QFileSystemModel need to have those plugins?  Do we need to have
>them installed at the machine of our users, in order to properly use
>QFileSystemModel within our application?

I think the filesystem model loads icons for the file types. If you don't 
have the image plugins, then it will only be able to deal with builtin 
image formats (XPM and PNG).

>At the moment, our application appears unstable, when it's using
>QFileSystemModel on a machine that does not have the plugins.  Is that a
>known issue?

No.

-- 
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/20090819/93676548/attachment.bin