Combination "HiOccur + wrap around + disabled word wrap" causes slow "find next"

[pintassilgo]

I was testing #5473 with new beta and Cuda is taking much longer to finish searching. So I tried some previous builds to warn you about which one caused the regression. But surprisingly all of them were equally bad. So I had a suspicion. I duplicated the file to make a copy with different name. As I expected, this new copy has the expected performance of previous builds, much better than the original file bug5473.txt.

I guess there's probably something associated to file in history session that can make find performance much worse. It shouldn't be this way, running find in files with identical content should have the same performance.

Later if I get more info I will comment here, if you cannot identify the cause of the issue in code based on this description.

[Alexey-T]

Do files 'settings/history*.json' have some big data? maybe big Undo/Redo data is stored?

[Alexey-T]

I see that 'sel_allow' option of HiOccur plugin affects it too. Option off: replace-all is 2s, option on: replace-all is 20s.

[pintassilgo]

Do files 'settings/history*.json' have some big data? maybe big Undo/Redo data is stored?

It has 105kb. But regarding bug5473.txt it has no undo data, so it's strange.

I see that 'sel_allow' option of HiOccur plugin affects it too. Option off: replace-all is 2s, option on: replace-all is 20s.

OK, but HiOccur makes no distinction between files, right? So it's not the culprit here. But I guess this is other thing that could be fixed, this impact you said shouldn't exist.

[Alexey-T]

If you remove history*.json files, slowdown disappears? if so, what data inside what file is the culprit?

[pintassilgo]

That's the interesting thing. If I remove these files, and of course reenable O, Hi and Im in find bar because they are stored in this file, it doesn't fix, it's still slow in bug5473.txt.

But if I disable cuda_hilite_occurrences, then it's fixed, with both bug5473 and its copy being equally fast.

So for some very strange reason, HiOccur is causing the slowdown but only for bug5473, not for its copy which is always fast.

[pintassilgo]

It's not related to pycache either, I deleted all the folders and it's still slow for bug5473.txt when HiOccur is enabled.

Somewhere there's a special data stored about bug5473.txt that causes this file to be slow, while an exact copy with other name is fast. And it's related to HiOccur.

[pintassilgo]

Just confirming one more time this issue is not related to undo history. len(ed.get_prop(PROP_UNDO_DATA,'')) shows the same value for both bug5473.txt and its clone, yet one is slow and other is fast.

As said, it's related to HiOccur, but I have no idea why HiOccur would treat files with the same content differently.

[pintassilgo]

New beta fixed the other issue, but doesn't affect this one.

[pintassilgo]

OK, so I'm as close as I can to the root of the issue.

It has nothing to do with undo, it's a combination of some factors:

• Hilite plugin.
• O and Im enabled in find bar.
• Word wrap must be disabled, at least for bug5473.txt.
• There should be no next match til the end of the file, so search wraps around to the start of the file because O is enabled (wrapped search).

After assuring if you Cuda meets requirements above, do this:

1. Place caret at the very end of the file (bug5473.txt).
2. Open find bar and type just m.

For me, it takes like 2 seconds to jump to next match, which is the first char from Mousepad in line 2630.

If you try again, but placing caret at the vert start of the file, find is processed much faster.

Conclusion: under these conditions, something is making Cuda struggle to wrap around to the beginning of the file.

Placing caret at the very end of the file or at very start should be the same in terms of speed, right? Because the distance from caret to the next match is the same in both cases.

Something is making wrap around to be slow under these conditions.

There are many suspects:

• Wrap around search (O button) is inneficient because the issue requires "find next" to wrap around to the beginning of the file.
• Find is inefficient when word wrap is disabled because the issue requires word wrap to be disabled.
• HiOccur is inneficient because the issue requires HiOccur.

[Alexey-T]

2sec work is here:

    if FEnableCaretEvent then
      Editor.DoEventCarets; 

In atsynedit_finder.pas : PlaceCaret(). investigating.

[Alexey-T]

made the fix; beta updated. I see no pause when I press 'a' with "Im" at the end of the file.

[pintassilgo]

Fixed, thanks!