The plugin slows down Notepad++ upon Search & Replace about elastictabstops HOT 6 CLOSED

It is a known issue that this has performance issues with large files (see #6). There are some heuristics in place to try to minimize how often the tabstops get recalculated. However, it is impossible to detect when Notepad++ is doing a find and replace thus it always recalculates them after every single instance is replaced unfortunately.

from elastictabstops.

See #6 (comment) for an experimental release that should address this issue.

from elastictabstops.

I don't know how technically possible it is, but an alternative solution would be to implement update throttling. If it turns out to be possible, here is how I would have done it:

If a change happens within 10ms* of the last change, then enter "throttle mode" (and tread this second change as if it happened in throttle mode). If a change happens in throttle mode; don't update the tabstops immediately but instead schedule the update to happen 10ms* in the future. If another change happens before the scheduled update, reschedule it to 10ms* after this change instead. The scheduled tabstop update also disables "throttle mode".

Note: 10ms is just a number I chose as an example, just make sure it's shorter than the fastest keyboard repeat rate setting (around 30ms).

from elastictabstops.

The way it works now is that it can aggregate several changes at once. Scintilla sends out notifications when changes are made. The plugin collects these until Scintilla says it is getting ready to redraw the screen, then the tab widths are recalculated. In theory a delay could be added but then it would force another screen redraw and I'm not sure what is optimal in that case.

from elastictabstops.

That sounds much better than what I described.

Note that I'm still using version 1.1 (custom build with elastic tabstops enabled for files with spaces) because I don't like the idea of the tabstops jumping around when scrolling. I would personally prefer having the change aggregation without the update-only-current-view part.

from elastictabstops.

I'm still on version 1.1 (custom build with elastic tabstops enabled for files with spaces)

v1.3 now allows this to be enabled for files with spaces.

I would personally prefer having the change aggregation without the update-only-current-view part.

Part of the problem is the there are 2 radically different use-cases for this plugin.

1. Source code editing - It is mostly straight forward to locate "blocks" of text where tabs should be stretched out (e.g. block comments, etc). Normally the plugin only needs to parse through a few lines of code each time. Many times it only needs to look at parts of the lines. There is little to no performance hit noticeable.
2. Tab delimited data - The plugin is incredibly helpful viewing data that is separated by tabs...however this means in most cases the entire file may affect column widths...and some data files are very large.

Alot of the difficulty is supporting both cases. To make edits quick, but also make "data columns" the appropriate widths without having to potentially parse alot of text.

from elastictabstops.