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

[David Nolden]

Am Sonntag 28 Februar 2010 15:20:06 schrieb Milian Wolff:
> 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?
> 
The contents should only be extended to the right, so caching based on the 
last call should be possible. However you should also notice that your test 
seems to be an extreme case, and I think I haven't seen this in my test 
projects, so we have to make sure that we don't speed up rare cases at the 
cost of slowing down the common case.

Greetings, David