Closed mrclary closed 3 years ago
Is there a way for us to test this more rigorously and more accurately? It seems someone had done programmatic testing when we had problems before...
It would be nice if we could include something in our unit tests that scored the performance in some way, perhaps using a large (~1000 line) file, and asserted the performance exceeded some minimum threshold.
Thanks for reporting this @mrclary. I think Edgar might know more about this. @andfoy can you please take a look at this one?
PR #13864 should have helped to solve latency issues, not introduce them again. That's because we're now waiting until a certain time before requesting symbols and folding, instead of doing it right after linting results arrive from the PyLS. In any case, I can't reproduce this problem on Linux and Windows.
What happens if you hide the class and functions selector?
I'll check it out...
Okay, I've used a more repeatable setup and determined that it seems to manifest in large files only.
I've installed the keyboard
package and used the following code to reproduce the issue.
In [1]: import time, keyboard
In [2]: time.sleep(3)
...: keyboard.write('The quick brown fox ', delay=0.05)
...: time.sleep(1.5)
...: keyboard.write('jumped over the lazy dog.', delay=0.05)
spyder/spyder/app/mainwindow.py
.I performed the above procedure both with and without the Class/Function Selector and there was no difference.
I've attached lsp logs and a spyder log (SPYDER_DEBUG=3 Applications/Spyder.app/Contents/MacOS/Spyder &> spyder.log
). There seems to me to be a glut of log messages nearly identical to the following that appear to correspond to every "keystroke", then log messages corresponding to the 1.5s intermission, after which the previous log messages resume a less frequent cycle.
Well, this is bizarre. I performed the tests on 4.2.1 and artifact from 14719 and got very poor results.
I'm wondering if it has something to do with the choice of keystroke cadence and intermission time. Could it be that sensitive to exactly which values I choose?
Why would I experience no issues typing in 4.2.1 or 14719, but with 4.2.2? Could my natural typing cadence be in poor resonance with 4.2.2 and not the others?
Would we be playing wack-a-mole by modifying timeouts, i.e. what works for some people causes issues for others? This seems to be an unstable prospect.
Very large latency at the intermission...
This actually hangs indefinitely...I had to force quit Spyder.
I forgot to mention that performing this test on 4.2.2 can cause Spyder to crash. server_python_47508.log transport_python_47508.log spyder.log
With all the following preferences enabled simultaneously, and indent guides and code folding disabled, there are no issues whatsoever.
With either indent guides or code folding individually enabled, the issue manifests.
Testing with bootstrap is even worse than with the macOS application. Even with indent guides and code folding disabled, it is extremely sluggish and consistently crashes Spyder. This could be due to Anaconda Python builds vs. Homebrew Python builds; not sure.
I have noticed the typing latency as described above in Spyder 4.2.3, Windows 10, Python 3.9.2. I was able to link the symptom to Kite running (no problem) or not running (typing is lagging). This happens regardless of the state of the switches in Completion and linting - Advanced - Providers - Enable Kite, Enable fallback completions being on or off.
This is also an issue in a blank file with nothing in it as long as Spyder stays open a few hours.
Issue is still present in 5.1.0dev0 6648e8632 (latest 5.x, PR #15149). Bootstrap is very bad. Working with the artifact, it seems to still manifest only in large files
I've gotten a report from a colleague that Spyder 5.0.0 continues to get worse the longer it is open. He has downgraded to 4.2.5.
Bootstrap is very bad.
If you're in Big Sur and using the defaults Anaconda channel, we can say for sure that that is caused by Qt 5.9 and there's nothing we can do about it (that version is too old for Big Sur).
Working with the artifact, it seems to still manifest only in large files
We're aware of that problem and we'll fix it in the next months. It requires an important refactoring in the editor.
I've gotten a report from a colleague that Spyder 5.0.0 continues to get worse the longer it is open. He has downgraded to 4.2.5.
Worse in what sense?
Bootstrap is very bad.
If you're in Big Sur and using the defaults Anaconda channel, we can say for sure that that is caused by Qt 5.9 and there's nothing we can do about it (that version is too old for Big Sur).
I'm reporting on Catalina, not Big Sur. But I can investigate more on Qt 5.9.
Working with the artifact, it seems to still manifest only in large files
We're aware of that problem and we'll fix it in the next months. It requires an important refactoring in the editor.
I've gotten a report from a colleague that Spyder 5.0.0 continues to get worse the longer it is open. He has downgraded to 4.2.5.
Worse in what sense?
This is anecdotal and I'm not prepared to quantify that. If we are refactoring the Editor soon, then I'd just as soon wait until then and revisit/retest this issue.
I'm reporting on Catalina, not Big Sur. But I can investigate more on Qt 5.9.
Ok, please check with 5.12 from Conda-forge. If the installer is working fine for you, I'd say that's the main issue.
I just upgraded to Big Sur and hit this issue. I also updated conda/spyder, and it persists. I'm at:
Spyder 4.2.0
Python 3.7.7 64-bit
Qt 5.9.6
PyQt5 5.9.2
Darwin 20.5.0
I am editing a short file (~20 lines). Kite is not installed. I unchecked code folding & indent guides: the issue persists.
@lamorton, I recommend using the macOS app bundle instead of the conda version of Spyder. I find it is more responsive. Let me know if that helps at all. But the typing latency, in general, is still an issue.
I, too, am having severe latency issues, here in Anaconda Spyder 5.1.1. I've updated whenever a new release comes out, and it keeps happening. The longer I keep the window open and keep editing, the worse (slower) it gets. I find myself closing Spyder and restarting it every 20-30 minutes just so I can keep working, which is a pain.
Ubuntu 20.04
Qt 5.12.9
conda 4.10.3 (installed from conda-forge)
Python 3.9.6, x64
pyqt 5.12.13
spyder 5.1.1
I'm on a 20-core Xeon machine with plenty of RAM, it's not even close to maxing out the machine, but it just starts spinning indefinitely on the one processor for reasons unknown. Doesn't seem like a text editor should be doing this (even with Kite, code-completion, etc). I am trying to see if downgrading spyder might help for a while, but if I can't solve it I'm likely just going to need to migrate to another programming environment and leave spyder behind. This is not a sustainable way to work, pressing keys and waiting around 5+ seconds for them to appear on the screen before going on. The Commodore 64's of my childhood were more responsive than this.
Using spyder/app/mainwindow.py
(~2000 lines). Both applications open for less than 20min and only one file open. Code folding and indent guides enabled.
@mmacferrin, most latency issues are fixed in our latest version (5.1.5). Please update.
@mrclary, the remaining issues are due to code folding and indent guides, which require a big refactoring in the editor to fix them. Please disable them and try again.
@ccordoba12, I can confirm that disabling both code folding and indent guides eliminates the issue, as far as I can tell.
With them enabled, playing around with SYNC_SYMBOLS_AND_FOLDING_TIMEOUTS
and testing on spyder/plugins/editor/widgets/codeeditor.py (~5500 lines), I see that if I set the timeout to less than 1500ms (the pause delay in my testing script) then the issue manifests. If I set it to larger than 1500ms, the issue does not manifest. This confirms your assertion that the issue is with the performance of the folding algorithm (indent guides depend on folding). Since a user's "delay" could be just about anything, the timeout cannot be used as a solution, but the performance of the folding must be improved considerably.
Indeed, spyder/plugins/editor/panels/utils.py::merge_folding takes 13-16s to complete! Ouch! It is the while loop in that function that is taking so long. For the testing algorithm I used, the loop iterates 1580 times. Within the loop, it is textdistance.jaccard.normalized_similarity
that accounts for the entire accumulated loop time.
I think I've got a very good and simple fix. I'll submit a PR shortly
So, I think this can be solved by changing the algorithm used by textdistance. Doing some experimentation, I found a few options:
Algorithm | Test time (s) | Loop size | Dist > 0.8 | Note |
---|---|---|---|---|
jaccard | ~15 | 1580 | 14 | this is what we currently use |
tanimoto | ~0.11 | 1580 | 0 | supposedly the same as jaccard but with different parameters |
overlap | ~0.08 | 1580 | 1333 | |
hamming | ~0.01 | 1580 | 14 | requires jellyfish optimization package available on conda |
I recommend using the hanning because it is by far the fastest, but also because it has the same number of iterations as our current algorithm that have a distance measurements above 0.8. This means that it is probably similar in its comparison of the texts. However, textdistance
documentation suggests that jaccard
is "token" based and hanning
is edit_based
, whatever that means. This may or may not make any difference to us.
The bottom line is that with these changes we can probably have one timeout, independent of the number of lines, and the typing latency should be solved without refactoring. :-)
Description
What steps will reproduce the problem?
After release of 4.2.2, I noticed typing latency in the Editor. I know that we had solved performance issues with Editor in the past, but it seems to have resurfaced.
I suspect the issue was introduced with PR #13864 since I don't see the issue in artifact from PR #14719.
Illustrated in the attached gif: note the hiccups while typing "jumped over the lazy dog". That sequence was typed (relatively) smoothly, but you can see the latency followed by bursts.
Versions
Dependencies