-
Notifications
You must be signed in to change notification settings - Fork 200
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Editor slows down in large documents #360
Comments
block.isVisible() is always True, check the rectangle to find out if it is really in the viewport. Break the loop if the block is below the viewport. Move some common variables outside the loop. Refs #360.
Do you have line numbers enabled? If yes, the linked commit (in master) may help. It would be nice if you could test it. |
I have now pushed some more optimizations to the master version, now editing large documents should be even faster. There is still a remaining problem with spell checker, but it affects only initial loading of the document, not editing it. |
I tried the 7.0.3 Version. However I did not perceive any performance gain. |
This is fixed in master branch, not in 7.0.3. It will be in the next release. |
The master branch version works now smoothly with about 7800 lines and line numbering enabled. |
Performance decreased again: I am on commit db20aaa ReText.ini
$ python --version |
Can you try to bisect in which commit it happened? |
By the way the newly introduced config link in the settings is not clickable (however right click + |
O.K. it seems that the performance did not decreased by the later commits (even with d9f0219 where you introduced the performance optimisations it is currently slow). I only see two differences: the document size increased: and I just moved from Windows 7 to 10. Haven tried it on Linux so far. |
Can you check if disabling line numbers and/or current line highlighting (maybe also spellchecker) makes it better? It would be nice to know if it's a problem in the editor itself or in the addons to it. |
I think I got the cause. It was the document stats which was slowing everything down. |
Ok, I will look at optimizing it. Maybe you can attach your document if it's not private? |
I am afraid. I cannot attach the document since it contains a lot of confidential data. Almost everything (~98 %) of the documents are headlines or lists. So you might generate it yourself. Probably just the amount of text(amount: see above)/lines (currently 4594 lines) should be already enough to reproduce it. |
No problem, I will generate it. |
I created two test documents. |
Can you please file a new bug for this, and attach a screenshot / paste what the link looks like for you? I have an idea what it may be, but I want to decouple it from this bug. |
I was able to improve statistics count performance by about 1/3 in the linked commit. Can you please check if it makes it any better for you? |
It seems better but there is still a certain noticeable lag. |
Maybe I will try to make statistics calculation asynchronous. |
I have a document with ~6400 lines of text. In this tab (but not in others) the delay between a keystroke and the displayed text gets notably high.
This should be improved.
The text was updated successfully, but these errors were encountered: