D11487: optimization of TextLineData::attribute

[Jaime Torres Amate]

jtamate added a comment.


  In D11487#230895 <https://phabricator.kde.org/D11487#230895>, @mwolff wrote:
  
  > Looking at `TextLineData::addAttribute`, it doesn't seem to sort the data - how can you be sure that the attributes list really is sorted by `offset + length`? I think this should be done manually there, or at least asserted. The old code apparently also relied on the order of attributes after all.
  
  
  For what I've seen in my traces, the attributes are sorted.
  How do you assert on the order of a list? I do not know how to do that.
  
  > @cullmann @dhaumann: can we have overlapping attributes? If so, then this opens another can of worms when we start to use binary searches over *ranges*.
  > 
  > Note that we could think about an alternative (could also be combined with your patch) approach to speeding up this function: 
  > Pass around the previously found position. 
  >  The way I guess this hotspot arises is that some function calls attribute on every pos in the line, linearly. We can leverage this and continue from where we left off the last time we returned.
  
  The function is KateSpellCheckManager::spellCheckWrtHighlightingRanges in src/spellcheck/spellcheck.cpp(176)
  I tried this approach. Didn't work for me. :-(
  You have to store that information in a pointer, because the method is const.
  
  > Really, I'd like to get my hands on one of your large XML files to play around with this myself :)
  
  I'll try to generate one :with no private data ;-)

REPOSITORY
  R39 KTextEditor

REVISION DETAIL
  https://phabricator.kde.org/D11487

To: jtamate, #frameworks, #kate
Cc: dhaumann, mwolff, cullmann, michaelh, kevinapavew, ngraham, demsking, sars
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20180321/13a43da6/attachment.html>