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