State of mmap for icon cache

Andreas Pakulat apaku at gmx.de
Tue Jun 17 12:20:04 BST 2008


On 17.06.08 12:59:27, Thiago Macieira wrote:
> On Tuesday 17 June 2008 10:22:25 Andreas Pakulat wrote:
> > Hi,
> >
> > I'd like to get a short overview of the current state of mmap support in
> > our pixmap cache. Last I checked it was disabled due to bug #160284, did
> > it get enabled again meanwhile?
> >
> > I just had a quick glance at kpixmapcache.cpp and it seems like it is
> > enabled again. So could the fixes that have been done for the mmap'ing
> > slow down icon loading that much? Because loading of icons has become
> > quite slow in KDevelop, I notice it in our project tree which uses
> > KIO::pixmapForUrl() or KIcon() constructor to load the icons. Another
> > developer has serious problems with the code-completion, it seems that
> > for him icons are read from disk over and over again (i.e. no caching at
> > all as it seems). I don't know how recent his kdelibs is though, as I
> > can't reproduce such a severe problem with the code-completion here
> > (up-to-date kdelibs as of yesterday).
> 
> I've got a refactoring of the mmap code using QFile::map(). I didn't want to 
> submit it while trunk is in feature freeze.
> 
> I'll submit when it's unfrozen.

Do you mind sharing this? I'd like to see wether KIcon and Co are really
suitable in our use-case (tons of icons loaded) or wether we just need
to switch to something different anyway. But before doing measurements
against KIcon loading or trying to find ways to remove KIcon&Co from
our code I'd like to see what improvements QFile::map() brings.

Andreas

-- 
You will be awarded the Nobel Peace Prize... posthumously.




More information about the kde-core-devel mailing list