Fix for makebuilder not opening properly files referenced by errors/warnings

Andreas Pakulat apaku at gmx.de
Mon Aug 18 10:07:55 UTC 2008


On 18.08.08 10:14:55, dizzy wrote:
> On Sunday 17 August 2008 11:34:41 Andreas Pakulat wrote:
> > Hmm, are you saying that the code does a QFileInfo::isRelative() check
> > each time you create a warning item (I should've read the patch a bit
> > closer)? In that case it might in fact be better to calculate it onlu
> > when the item is activated...
> 
> Yes, I checked that relative thing on each created warning/error item because 
> I did not wanted to have memory overhead (storing the current build dir in the 
> item) if the file path of the item is not relative (in which case it wouldn't 
> be needed when activated). So you are saying creating a QFileInfo is expensive 
> CPU wise to do it on each warning/error item. 
> 
> That comes with the compromise that we will need to store the current build 
> dir with each warning/error created item even if the item does not need it 
> (because it may already have full path to the file from gcc). Is this ok? 

Without profiling it we can't know wether the creation of QFileInfo is
expensive enough to warrant the memory overhead. But I can tell you that
checking anything with QFileInfo involves creating a QFileSystemEngine
which isn't quite a cheap operation. TT did some improvement for checks
such as isRelative in 4.4.0, but they couldn't get rid of creating a
QFSEngine. OTOH attaching a string to each item might be a problem too
if there are a lot of errors... 

> This is a classic memory/CPU tradeoff and I'm asking about it because I'm 
> completely kdev/kde illiterate so I can't make any educated guess which one is 
> better.

Well, for now I'd say do whatever is easier to do code-wise. We can
worry about the speed or memory overhead once we find out its actually a
problem :)

Andreas

-- 
Tomorrow, you can be anywhere.




More information about the KDevelop-devel mailing list