D11487: optimization of TextLineData::attribute
Milian Wolff
noreply at phabricator.kde.org
Fri Mar 23 09:55:38 UTC 2018
mwolff added a comment.
In D11487#231656 <https://phabricator.kde.org/D11487#231656>, @jtamate wrote:
> In D11487#231522 <https://phabricator.kde.org/D11487#231522>, @mwolff wrote:
>
> > @jtamate looking at your screenshots, it represents closely what I see locally. Most notably, there are no red underlines in your screenshots which could arise due to spell checking. Thus I really wonder why you are seeing such a big hotspot there.
> >
> > Try perf, or try a poor mans profiler like GDB and regularly interrupt. Do you really end up in `TextLineData::attribute()`? Or, alternatively: Measure the time it takes for kate/kwrite to open the file and then go to the end. Then compare this before and after your patch. Do you see anything in the order of ~75% reduction for the time then too? Note how callgrind only measure instructions, so a supposed reduction of 75% of instructions should certainly have an impact on time too - of course not 75% too... I simply cannot fathom why you are seeing such an impact but I cannot reproduce this at all!
>
>
> I've done some measurements, as the times are so big, with a stopwatch 2 times each test.
> With "Enable autodetection of Language" and "Automatic spell checking enabled by default" enabled,
> the test as before: since pressing "Temporarily raise limit and reload file", press Ctrl+end and finish the scroll to the end of the document.
>
> without any version of the patch:
> 1 min 25 seconds
> With @mwolf solution, used only in spellCheckWrtHighlightingRanges.
> 38 seconds
> With the binary search:
> 34 seconds
OK, this is a huge win, so I guess one way or another we should integrate this patch. One question to that though: Why do you sort/lookup by `x.offset + x.length <= p`? Note how lower_bound returns the first iterator that is _not_ going to return true. To me, it looks like your code cannot actually work and will always return 0? Personally, I'd try to use `upper_bound` with `x.offset < p` in the comparison. The iterator should then point to the first item that has it's offset larger than `p`. So decrementing the iterator once (while checking against `begin()`) yields the iterator that could potentially match. Thus, check if `p` is contained in its range and if so return it's attribute, otherwise return 0.
Besides this: I am still looking for an explanation why spell checking is so extremely slow for you. I have the same settings enabled, and spell checking is seemingly fast for me... Am I missing some dictionary or something other to reproduce this?
REPOSITORY
R39 KTextEditor
REVISION DETAIL
https://phabricator.kde.org/D11487
To: jtamate, #frameworks, #kate
Cc: anthonyfieroni, 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/20180323/93c2aa2c/attachment-0001.html>
More information about the Kde-frameworks-devel
mailing list