From kde-core-devel  Fri Mar 07 22:18:48 2008
From: Ralf Habacker <ralf.habacker () freenet ! de>
Date: Fri, 07 Mar 2008 22:18:48 +0000
To: kde-core-devel
Subject: Re: 'lightweight' QDir::isAbsolutePath replacement ?
Message-Id: <47D1BF48.4020609 () freenet ! de>
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=120492893919346

Lubos Lunak schrieb:
> On Thursday 06 of March 2008, Aaron J. Seigo wrote:
>   
>> On Thursday 06 March 2008, Ralf Habacker wrote:
>>     
>>> The only static method Qt provides to handle this platform independent
>>> is QDir::isAbsolutePath(). Unfortunally this method seems to be very
>>> time expensive because it creates a temporary QDir instance.
>>>       
>> just to support this point, when doing some profiling and optimization for
>> icon loading leading up to 4.0, this was at the very top of the profile in
>> the KIconLoader! just changing that to a "by hand" check knocked off a huge
>> chunk of the execution time (i forget the exact #s, i blogged about it
>> though; by the end it was something like a 5x speed up over all, though,
>> and this was a big part of that)
>>
>> so if we could have something light weight in kdelibs that would be great.
>>     
>
>  As much as I grumble about and generally hate qt-bugs@, I disagree. If 
> QDir::isAbsolutePath() path has a performance problem, fix it, send the patch 
> to TT and put it to qt-copy/patches. That's one of the reasons it's there.
>   
Thiago has announced that qt4.5 will have some optimations in this area 
- but this will probably in 2009 - this is to late for kde 4.1 and would 
the optimations will reach the requirements Aaron has stated ? 

QFileInfo needs three additional classed QFileInfoPrivate, QFSFileEngine 
and QFSFileEnginePrivate. I doubt that there will be a solution possible 
as fast as the suggestions I made extending QFSFileEngine and/or 
QFileInfo with static methods.

But - now the main question - is anyone from the trolltech devs here who 
can ensure that such a patch would be accepted ?

If yes, then making a related patch and sending to TT will be the best 
option.

If not, a kdelibs located implementation will be the next best option, 
maybe replaced later by a qt based implementation.

Any comments ?

Ralf