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

[Milian Wolff]

On Wednesday 03 March 2010 01:04:56 David Nolden wrote:
> 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.

Imo this cannot negatively effect the "common case" if it's _always_ only 
appended to the right! The cache should always be faster (maybe not for empty 
lines or something).

I'll have a look at it again and try to introduce such a cache if you don't 
have the time to do so. But imo this should positively affect Cpp performance 
throughout the projects as that method is called everywhere, it's just not as 
slow for lines with ~80cols. But even there useless time is spent just to get 
some lengths imo.

Also note that such files are probably very common in that regard as they are 
shipped with boost which is used really often. And I bet other frameworks 
(maybe even stl or qt) have similar files - maybe just not that insane :)
-- 
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/20100303/5b8e7112/attachment.sig>