PR: Change update_all to update_current on editor changes

[bcolsen]

Description of Changes

This is more of a simple proof of concept

• Wrote at least one-line docstrings (for any new functions)
• Added unit test(s) covering the changes (if testable)

• Included a screenshot or animation (if affecting the UI, see Licecap)

Removed update_all from activating on current editor changes.

Issue(s) Resolved

Fixes #10992

Affirmation

By submitting this Pull Request or typing my (user)name below,
I affirm the Developer Certificate of Origin
with respect to all commits and content included in this PR,
and understand I am releasing the same under Spyder's MIT (Expat) license.

I certify the above statement is true and correct: bcolsen

[ccordoba12]

This is more of a simple proof of concept

What do you mean?

[bcolsen]

It only fixes part of the problem, which is better than nothing. I explained a bit more on #10992

And it needs to be refactored to remove repeated code and debased on 4.x

I would also like to hear from @impact27 on any reason he might have for need update all the files.

[impact27]

I would also like to hear from @impact27 on any reason he might have for need update all the files.

I can't see any reason for the need to update all the files except that it was done this way before.

[ccordoba12]

@bcolsen, thanks a lot for your prompt response to solve this nasty problem! However, I think you could improve your solution a little bit by implementing @CAM-Gerlach's suggestion:

In addition to only updating the current file, it should also not update if the outline explorer isn't even visible (as my testing confirms it does now).

[CAM-Gerlach]

Thanks @ccordoba12 . I wasn't sure if was considered in scope here, so I only posted on the issue as opposed to potentially derailing the PR.

[bcolsen]

However, I think you could improve your solution a little bit by implementing @CAM-Gerlach's suggestion:

In addition to only updating the current file, it should also not update if the outline explorer isn't even visible (as my testing confirms it does now).

How does a plugin know that it's visible?

I think that we need to update the oe_data to get the code cell names for runcell. @impact27? I guess we would only need to update the data before the code cell execution.

[impact27]

I think that we need to update the oe_data to get the code cell names for runcell. @impact27? I guess we would only need to update the data before the code cell execution.

If I am not mistaken, the oedata is generated by the syntax highlighter. So this wouldn't affect cells name detection.

[ccordoba12]

How does a plugin know that it's visible?

You can use the _isvisible attribute of BasePluginWidgetMixin:

spyder/spyder/plugins/base.py

Line 385 in cfa90bf

self._isvisible = enable and visible

[bcolsen]

I there is significant difference when the outline tree updating is disabled, but there is still something keeping it from being smooth. It's probably the syntax highlighting.

I'll make another issues to track possible optimizations that could be made to the outliner's populate_branch function. That seem to be where the slow down is.

[bcolsen]

I'm not sure what the fast tests are doing. Should I add _isvisable to Code Editor as well?

[ccordoba12]

@CAM-Gerlach, could you test this one to see if it works for you as expected? Thanks!

[CAM-Gerlach]

@ccordoba12 In work now.

[CAM-Gerlach]

No errors etc. running this, and there is a major performance improvement when I tested on a 100-line file and a 3000-line file with and without this PR, with the same 40-50 files open as before. For the test, I used default/clean settings which means indent guides, otf completion, code style warnings, etc. are all disabled, to reduce the impact of other variables that might slow down the editor. Measuring lines modified/deleted (holding down Ctrl-D) per second and total measured time to delete 100 lines of the file, performance improvement/lag reduction is anywhere from 3x/67% to 2x/50%, showing substantial improvement even in the worse case.

100-line (test.py), outline explorer closed: 10.5 lines/s / 9.5 s (with PR); 3.4 lines/s / 28.9 s (without)
100-line (test.py), outline explorer open: 7.9 lines/s / 12.7 s (with PR); 3.4 lines/s / 29.1 s (without)
3000-line (mainwindow.py), outline explorer closed: 5.4 lines/s / 18.5 s (with PR); 2.4 lines/s / 41.6 s (without)
3000-line (mainwindow.py). outline explorer open: 4.6 lines/s / 21.7 s (with PR); 2.3 lines/s / 43.9 s (without)

For reference, if I do the exact same thing in the same file in Notepad++ (also with syntax highlighting, etc enabled), I get:

100-line file: 26.7 lines/s / 3.76 s; 3000-line file: 26.6 lines/s / 3.77 s

(With about 0.5 s being keyboard first-repeat delay, and it might well be deliberately limited).

For the 3000 line file it seems quite probable it was the syntax highlighter causing most of the slowness, since the great majority of the slowdown with the PR applied on the short vs. the long file was the was the comparatively large (1-2s) lags when the first or last line of a docstring """ was deleted and everything was rehighlighted. There's a good chance that fixing this would also fix the very similarly-behaved slowness that the indent guides cause, if it ultimately comes down to the same thing (the redraw blocking the main thread) as opposed to anything specific to them.

[ccordoba12]

Thanks a lot @CAM-Gerlach for the comprehensive testing!

[ccordoba12]

Great work @bcolsen!! Thanks a lot for it!