mwolff added a comment.
In D11487#230913 <https://phabricator.kde.org/D11487#230913>, @jtamate wrote: > 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. You assert that newly added items actually sort-after the last added item in the vector >> @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. we can return the iterator and take it as an argument again >> 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 ;-) thanks :) REPOSITORY R39 KTextEditor REVISION DETAIL https://phabricator.kde.org/D11487 To: jtamate, #frameworks, #kate Cc: dhaumann, mwolff, cullmann, michaelh, kevinapavew, ngraham, demsking, sars
