Skip to content
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

Highlight current cell slows down the Editor on big files #1793

Closed
spyder-bot opened this issue Feb 17, 2015 · 8 comments
Closed

Highlight current cell slows down the Editor on big files #1793

spyder-bot opened this issue Feb 17, 2015 · 8 comments

Comments

@spyder-bot
Copy link
Collaborator

From ccordoba12 on 2014-04-16T10:07:43Z

Example: Open "spyderlib/spyder.py" and try to move up and down maintaining the arrow keys pressed.

When "Highlight current cell" is on you cannot see the cursor moving through the lines, just jumping from one line to another after a couple of seconds. When it's off there is no noticeable slow down.

Problem is (I think) with any cursor movement "select_current_cell" is called, which is quite costly when the file is big and there are no cells in it.

Solution could be to solve issue #1556 first to know if there are cells in a file and where their positions are, to be smarter when calling the mentioned method.

Original issue: http://code.google.com/p/spyderlib/issues/detail?id=1793

@spyder-bot
Copy link
Collaborator Author

From sylvain....@gmail.com on 2014-04-16T08:13:12Z

Ok, this is another reason to improve the logic of select_current_cell, or shall we just deactivate it on large files?

@spyder-bot
Copy link
Collaborator Author

From ccordoba12 on 2014-04-16T08:27:26Z

But what is a large file? :) (I mean under what criteria we could decide that?)

The real solution is just to improve the logic as you said, until is quite efficient (i.e. only applied when it's needed). I think the info provided by the outline explorer could be enough for that.

@spyder-bot
Copy link
Collaborator Author

From sylvain....@gmail.com on 2014-04-16T15:00:09Z

Actually, the problem is not really about large files but more about large cells. A large file split in many small cells is not a problem...

@spyder-bot
Copy link
Collaborator Author

From sylvain....@gmail.com on 2014-04-16T15:46:38Z

The implementation of select_current_cell itself has to be improved, I am already looking into it. Although, as long as we keep using the logic of exploring around the current position of the cursor, it will not scale to huge files, even if our implementation is faster.

  1. An optimization that would be scalable to store the TextCursor returned in the last call to select_current_cell. Then, if the file has not been modified since the last call and the current cursor position is still within the last selection, return the last selection. Otherwise, recompute it.

  2. We could also limit the search to the visible section of the screen? Then, it will be difficult to disable cell coloring if no cell separator is present in the file.

  3. Complete new logic, much more coding: maintain a list of lines containing separators, and use binary search in the current line. Only update the list on operations that change the content of the file.

What do you think of it?

@spyder-bot
Copy link
Collaborator Author

From ccordoba12 on 2014-04-17T06:36:46Z

I don't know how well options 1 and 2 would work under the situation I described at first, i.e. by moving the cursor with the arrow keys continually pressed. You could try to implement option #1 first and see if it works.

But I think option 3) is the best one. You could obtain the list of lines with separators from the outline explorer data, if you solve issue #1556 first. Then you'd just need to check if the cursor is between those lines before applying select_current_cell.

@spyder-bot
Copy link
Collaborator Author

From contrebasse on 2014-04-17T14:15:31Z

It seems to me that 1) or 3) could work but 2) seems wrong.

If it is still too slow, another option is to wait for the cursor to top for a while (like 100ms). Restart the timer on each cursor move and compute the coloration only when the timer expires. This introduces some lag in the interface but it can be very efficient.

@spyder-bot
Copy link
Collaborator Author

From sylvain....@gmail.com on 2014-04-17T14:43:18Z

I have implemented (1). It works well in the example of Carlos (maintaining arrows pressed). However, while typing (an making modifications to the documents), it starts being noticeably slow for files of 15-20k lines.

Regarding (3), I don't think that it can work, because every time you modify the document by typing (or copy-pasting long pieces of code), you may need to go over the whole file again to update the list of delimiters. In other words, maintaining a list of delimiters is as expensive as the previous solution.

I can make a PR with my implementation of Solution (1) if this is what you prefer, but eventually, I think the cleanest thing to do is either to disable cell coloring for cells of more than a couple hundred lines, simply because in this case, highlighting is pretty much useless...

@spyder-bot
Copy link
Collaborator Author

From ccordoba12 on 2014-05-24T07:12:10Z

This issue was updated by revision 19cb21e779cc .

Status: Fixed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant