PgUp/PgDown scrolling slow in large files with softwrap enabled

[Profpatsch]

If you open a large-ish file micro will have no problem scrolling line-by line (holding arrow down).
But when you use PgUp/PgDown to scroll a full screen-height, it takes over a second per page.

Example file: https://download.geonames.org/export/dump/cities15000.zip after extraction, which is only 33k lines and 7MB.

It feels like the page scroll is O(n) in file-size, maybe it tries to figure out all line-endings first.

Version: 2.0.14
Commit hash: 5b6eed5

[neurocyte]

This is a pretty brutal test case. The file has many long lines with a huge range of unicode characters involved. Micro actually handles it pretty well here. Not quite as fast as some other editors (😉), but definitely more than fast enough. It might well be your terminal that is lagging though. Handling a large range of unicode codesets is something that causes many terminals to perform really poorly.

[Profpatsch]

Updated to 2.0.15, same problem (maybe slightly faster?)

Shouldn’t the terminal only see the the displayed screen? I think my terminal (alacritty) has no problem showing a screenful of unicode in a few milliseconds.

I don’t see why determining how far to jump and rendering a single page should take more than 1s, especially when normal scrolling by a single line at a time is for all intents and purposes instant (I’m pretty sure if the PgDown was implemented as “take screen height and for-loop over “jump a single line” it would be faster than the current implementation)

[Profpatsch]

Fwiw it looks like both are implemented by BufPane.Scroll(), which is an interface method that is implemented in softwrap.go. And it looks like for-looping over single lines is precisely what it boils down to.

It smells like there’s an optimization here somewhere.

[Profpatsch]

Ah yes, if I > set softwrap 0, PageUp/Down are fast.

[JoeKar]

Fwiw it looks like both are implemented by BufPane.Scroll(), which is an interface method that is implemented in softwrap.go. And it looks like for-looping over single lines is precisely what it boils down to.

It smells like there’s an optimization here somewhere.

The expensive operation here, while looping over every step-ed line, is w.getRowCount(s.Line) (number of softwrap-ed lines) which furthermore depends on counting the characters, which depends on transforming the bytes into the unicode characters first.
So yes, we loop over every byte in every line.