let's optimize: Project::itemsForUrl

Milian Wolff mail at milianw.de
Fri Sep 9 14:45:50 UTC 2011

Hey all,

the function Project::itemsForUrl is *really* slow when we look at the total 
amount of time spent in there when parsing a biggish project. I just did that 
(with a simple QTimer and a static elapsed counter) and the last output was:

QList<KDevelop::ProjectBaseItem*> KDevelop::ProjectPrivate::itemsForUrl(const 
KUrl&) const elapsed time: 56870 

Yes, nearly a minute was spent in that function. So I would really like to 
improve that.

The code/apaku already mentions this:

        // TODO: This is moderately efficient, but could be much faster with a
        // QHash<QString, ProjectFolderItem> member. Would it be worth it?

I'm pretty sure he meant ProjectBaseItem. The question is, how to keep that in 
sync. We could put that into the ProjectModel and update it on every call to 
setUrl (if model()) and in setModel. I'm not so sure on the memory 
requirements though. We could of course just reuse IndexedString's new 
indexForString method, so the mem requirement would be (sizeof(uint) + 
sizeof(ProjectBaseItem*)) * N_items. Which is only a bit more than a megabyte 
on my machine (64Bit) for 100k items.

What do you think? Any other ideas? I also thought about comparing the start 
of the urls: If we could expect to have a proper hierarchy in the model, that 
follows the URL path hierarchy, that could be leveraged to improve the 
performance as well, by returning early. But I'm not so sure if that could be 
done without breaking stuff, as e.g. the URLs inside targets don't follow the 
URL hierarchy.

I think I'll give my IndexedString idea a shot and see how it goes. 
Objections? Hints?

Milian Wolff
mail at milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20110909/7509373b/attachment.sig>

More information about the KDevelop-devel mailing list