Perfomance_1_4_15

DSpellCheck. Thoughts on performance. (1.4.15)

Origin

The recent (after 7.8) Notepad++ updates made some problems with plugin performance more observable. (#195) Additionally there is long standing issue of noticeably slower scrolling when underlines are shown.

Current State

Rechecking is always performed on whole visible area currently. Prior to version 1.4.4 it was done from first visible line to the last, possibly rechecking invisible parts beyond left and right borders.

Rechecking only changed parts of the file might become significant productivity boost but unfortunately it might not be easy even with scrolling changes only, hard parts currently are caching which lines are visible for each file, determining which parts of each line became visible and so on.

On editing it might not even be needed as rechecks are done through timer and relatively infrequent.

Current solution in 1.4.15 is to throttle amount of checking done on notification through timer (currently 100 ms) which allows plugin to be a lot less intensive in terms of cpu time used. However it changes visual experience slightly as updates do not happen momentarily.

Profiling

Here's some profiling data of interesting functions for various cases for 1.4.15 and N++7.8.1:

1. GDI (Current N++ engine)

a) Wheel scrolling, normal amount of underlines:

Scintilla::Editor::Paint - 68.49%
   \- Scintilla::EditView::DrawLine - 39.45%
SpellChecker::check_text - 10.17%

b) Arrow scrolling, normal amount of underlines:

Scintilla::Editor::Paint - 65.76%
   \- Scintilla::EditView::DrawLine - 39.76%
SpellChecker::check_text - 16.83%

c) Wheel scrolling, every word underlined:

Scintilla::Editor::Paint - 70.19%
    \- Scintilla::EditView::DrawLine - 62.04%
SpellChecker::check_text - 9.30%

d) Arrow scrolling, every word underlined:

Scintilla::Editor::Paint - 90,49%
    \- Scintilla::EditView::DrawLine - 80.17%
SpellChecker::check_text - 0.89%

e) Moving cursor up and down without scrolling (no spell-checking is redone), every word underlined:

Scintilla::Editor::Paint - 95.42%
    \- Scintilla::EditView::DrawLine - 90.04%
SpellChecker::check_text - 0%

2. D2D (not enabled in N++ currently)

a) Wheel scrolling, normal amount of underlines:

Scintilla::Editor::Paint - 60.37%
    \- Scintilla::EditView::DrawLine - 15.44%
SpellChecker::check_text - 12.39%

b) Arrow scrolling, normal amount of underlines:

Scintilla::Editor::Paint - 44.49%
    \- Scintilla::EditView::DrawLine - 14.81%
SpellChecker::check_text - 21.21%

c) Wheel scrolling, every word underlined:

Scintilla::Editor::Paint - 47.40%
    \- Scintilla::EditView::DrawLine - 29.83%
SpellChecker::check_text - 13.69%

d) Arrow scrolling, every word underlined:

Scintilla::Editor::Paint - 71.48%
     \- Scintilla::EditView::DrawLine - 45.66%
SpellChecker::check_text - 3.35%

e) Moving cursor up and down without scrolling (no spell-checking is redone), every word underlined:

Scintilla::Editor::Paint - 85.88%
    \- Scintilla::EditView::DrawLine - 56.97%
SpellChecker::check_text - 0%

*Important note: since high cpu usage/lags noticeable differently in different cases, probably only slow cases should be taken into account (e.g. with a lot of underlines)

As we can see arrow scrolling is a bit more stressful even with timer since it's easier to provide incessant amount of updates that way. D2D hugely helps with drawing (probably pushes at least some work to GPU) and yet does not remove the problem completely with its own DrawLine function being bottle-neck.

Not covered by this profile data but even with invisible underlines there seem to be some bottle-neck stemming from large amount of message being sent in case of arrow scrolling with huge amount of underlines. Possibly this could be considered Scintilla api limitation.

Conclusions:

• Turning on usage of Direct2D in N++ may be helpful especially for significant amount of underlines.
• Still some speed-up of drawing underlines in Scintilla is necessary for large amount of underlines.
• From DSpellCheck side possible work on lowering amount of underlines updated might be done, but above points would still hold overall performance down as seen in cases 1e, 2e. However amount of messages sent would be lower which is important if underline drawing would be sped up.