Notepad3
Notepad3 copied to clipboard
rizonesoft
Slow undo for block selection edit
Undo for a delete on a block selection is very slow (with >50 rows ). In fact the delete also feels a bit too slow. Tried the same in Notepad++ without recognizing any delays. The width of the block does not matter. Edit: maybe to amount of not visible rows is the reason?
To reproduce:
- select a block over 250 rows
- delete
- undo
for convenience:
ABCDEFGHIJKLMNOPQRSTUVWXYZ abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ abcdefghijklmnopqrstuvwxyz
Performance Profiler Analysis shows, that 75% of CPU cycles are done inside Scintilla Lib (Rectangle / LineLayout, etc.) and 25% of CPU cycles are caused by "Scintilla notifies Notepad3 about document change", which is needed for restoring (redo/undo) Selection (a feature, that most Scintilla based Editors don't have). One problem here is: The notify change is called for every changed line instead of once per complete undo/redo transaction. Another question is, what changed Scintilla intern (75% CPU cycles) causing some slow down 🤔 ... PR #3858, should have a minor speedup to this issue.
Undo for a delete on a block selection is very slow (with >50 rows ). In fact the delete also feels a bit too slow.
Hello @RealMalWare
Feel free to test the "BETA/RC PortableApps", version "Notepad3Portable_5.21.1211.1_beta.paf" or newer, see 1st list in issue #1129.
"Notepad3Portable BETA/RC PortableApps" version can be used with or without ".7z" extension.
Also, feel free to test the "BETA/RC Setup", version "Notepad3_5.21.1211.1_beta_Setup" or newer, see the 2nd list in issue #1129.
Comments and suggestions are welcome... 😃
Thanks for the build. Yes, there is speed improvement. But it's still a little pita. And just for reference: the delay also occurs when pasting a large block into another/new document.
Didn't realize the selection recovery isn't available in other editors or even that it is integrated in NP3. I like it and used it quite often already :)
@RealMalWare : Thank you for the hint (performance issue) with pasting clipboard into new document. This uses other code paths than "undo rectangular selection" and so I was able to fix the performance issue (calling change notification on each line -> calling change notification only at transaction end). But this will not help to solve the 1st issue (title).
And just for reference: the delay also occurs when pasting a large block into another/new document.
Hello @RealMalWare ,,
Feel free to test the "BETA/RC PortableApps", version "Notepad3Portable_5.21.1212.1_beta.paf" or newer, see 1st list in issue #1129.
"Notepad3Portable BETA/RC PortableApps" version can be used with or without ".7z" extension.
Also, feel free to test the "BETA/RC Setup", version "Notepad3_5.21.1212.1_beta_Setup" or newer, see the 2nd list in issue #1129.
Comments and suggestions are welcome... 😃
Just tested block pasting with the new build - way faster 🥳 For large blocks twice the speed of N++ if new lines are created. And much faster if no new lines are created.
What I noticed while testing :
- pasting a large block (1500+ rows, sample above) into a new doc is fast
- pasting at the same postition again is fast
- pasting into the same doc with the cursor moved after the last character (last row, last col) it's slow (scroll bar moving slow)
- it's faster if the cursor is at last row col 1 (scroll bar moving fast)
(Same with Scite and N++ (but much slower than Scite - it even hangs a few seconds sometimes))
It seems as if the new lines are created at ones if the cursor is at pos 1. And only after each line past in the other case. Even with smaller blocks the differnce can be noticed. Maybe that behaviour can help with the original issue or for filing an issue for Scintilla.
I just opened a ticket for Scintilla/Scite for the pasting behavior:
https://sourceforge.net/p/scintilla/bugs/2302/