Performance: rpp::LocationTable with const ref of PreprocessedContents?

Milian Wolff mail at milianw.de
Sun Feb 28 14:20:06 UTC 2010


Hello all, esp. David:

As you might have seen: I did some profiling and found a bottleneck in the Cpp 
plugin. See also https://bugs.kde.org/show_bug.cgi?id=215968#c31

I wonder how we could improve the situation. The simplest would of course be 
to cache the result of the last positionAt call. Sadly this is not as easy as 
in the kdev-pg-qt case.

The thing is that the positionAt gets called while the contents get filled, at 
least it's size changes and I'm not sure whether contents get only appended or 
contents get changed somewhere in between (macros?). If stuff only gets 
appended, one could easily implement a cache like the following:

- make LocationTable take a pointer to the PreprocessedContents in it's Ctor 
and store the pointer. drop the (unused) ctor that takes no arguments
- make all methods operate on these contents
- in positionAt implement a cache based on the last call

Ideas? Comments?
-- 
Milian Wolff
mail at milianw.de
http://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/20100228/0c3dabfd/attachment.sig>


More information about the KDevelop-devel mailing list