KIconLoader Optimization Idea

[Koos Vriezen]

Simon Perreault wrote:
> On Monday 06 June 2005 11:04, Martijn Klingens wrote:
> > Another option that might be worth pursueing (but is very difficult to
> > write reliably!) is to do all file I/O with icons in a thread. The app can
> > then continue to start up, assuming I/O itself is not the bottleneck. (And
> > if it is, then shared memory or anything else won't help much. After all,
> > if the shared cache misses the file you still need disk I/O, and if the
> > shared cache has the file then chances are that the kernel's file cache
> > also still holds the icon.
> 
> I think that solution is much better, but incredibly hard to write.

I wouldn't worry about the I/O bottleneck, the idea was to have a cached
icon system. So when an icon is already loaded by another app, it's in
the OS's disk cache, no? (btw. that also makes me wonder if a
specialized caching system would really speed things up. Although being
special, it does not have the auto clearing on memory pressures or
umount. Only the sharing of XPutImage keys makes sense to me).

Anyhow, I also think threading would be the real solution. I don't think
it's that difficult to write. Simply put the requested filename in
thread's list and thread starts loading. When the images really get
displayed, then it needs all the data and joins the loading thread if
it's not fully there yet. However, looking at the QPixmap class, this
will probably only work for QImage if any of the Qt's classes. QPixmap
does not look to be designed for third party data retrieval..

Koos