scrolling performance very slow (scrolling)

[rdrms]

Description of the problem or steps to reproduce

Perhaps related to #1108
I ssh into another machine, then run micro on that device, open a somewhat large file (longer than one page) and use the arrow keys to scroll down, and down, and down past the first page (so it has to start updating the screen), then let go of the arrow key. It will continue to scroll, very slowly line by line, for a long time after you've stopped pressing down.

Specifications

The "server" is a laptop with an AMD E2-1800 APU, basically a 10 year old laptop so it's not very fast. But it is not running any graphics, and every other text editor I tried (namely nano, vim, and tilde), and I also tried locally on the laptop and the the same issue occurs on both Debian and Ubuntu. I forget if I tried it on CentOS.

Commit hash: Version: 2.0.8
OS: running Micro on Debian bullseye, connected to via SSH from both Ubuntu 21.10 and Android 12
Terminal: happens on both Tilix and GNOME Terminal (both VTE based), and kitty terminal on the desktop. As well as Termux and JuiceSSH on Android.

I am using zsh on both the host (server) and desktop and pretty sure Termux is running bash, but there doesn't seem to be a difference if I switch to bash on desktop. or on the server before running micro
Here's the issue happening on my 100 line .zshrc using Termux (Android app) using ssh to connect to the server. I enabled the option so you can see when I'm tapping, the scrolling is happening long after the taps have ceased.
https://user-images.githubusercontent.com/2936638/150813638-ccde2bdd-e1ac-4c86-ba2d-912421949670.mp4

[mrx23dot]

How does the speed compare to nano text editor?

[rdrms]

Here's a screencast of me doing the same thing (scrolling through my ~100 line .zshrc) in nano.

output.mp4

As you can see, it doesn't display this issue, and you can probably get from the top->bottom->top in nano before you can get to the bottom in micro

I remember the tilde editor people boasting about doing something for ssh performance but I can't find it now.

Edit: sorry, had to switch to desktop to figure out how to upload the file

[mrx23dot]

Hmm to me micro 2.0.10 is almost as fast as nano, maybe a few 10ms slower. Scrolling stops in ~50ms.
there is some lag when scrolling out of page because micro goes down 1by1, nano does pageDown.

Tested with windows+kitty to aws debian10+openssh at 20ms ping.
Try to update micro to latest, run it with kitty or mobaxterm, maybe check your htop if server load is high when scrolling.
Try it on a different server too. (eg linode has 1hr billing)
Can't comment much on technical root cause.

[mrx23dot]

It's a bit slow ~100ms when the text is colored/highlighted.

[rdrms]

I swapped over to KDE neon (bad habit, distrohopping), and konsole displays the same behavior with ssh into the Debian machine. If you watch the video closely from the first post, I stop tapping the down key quite a few seconds before the scrolling actually happens and then stops. Doesn't appear to be an issue related to the slow laptop server either, it never reaches over 10% CPU on the two cores, additionally nano's response is pretty much instant. Like I mentioned, you probably can get to the bottom and back to the top in the time it takes micro 2.0.8 to get to the bottom because every down arrow is super slow when it has to scroll the page in micro. emacs takes a different approach, keeping the current line centered, but it scrolls just as fast as nano while changing the screen to the new position.

One thing I should note is that the laptop server does not have Xorg installed, but does have xclip. I tried setting the clipboard to internal or terminal, and mouse toggled off, with no result.

I tried with micro 2.0.10 and the same issue happens there. I'd be happy to try something to try and isolate and find out why it's happening, as micro is an interesting editor, but since it's so slow in my use case I'll probably be using something else for the time being.

[mrx23dot]

One last thing you could try is headless server, window manager might affect micro some way. Just spin up a VM or VPS.

[rdrms]

Oh, interesting. I grabbed a spare keyboard and attached it to the laptop server. It doesn't appear to have anything to do with SSH, as the behavior was also present when running micro locally. Something about micro doesn't like the limited hardware of the laptop, but other text editors don't seem to have a problem. Weird. Sorry for the confusion!

I wasn't able to reproduce it in a Debian VM (running the same version as the laptop), so it's definitely something weird happening with that specific hardware.

It has 4GB of RAM, and so did the vm, so I don't think it is a limitation of the RAM. Here's the first half of cat /proc/cpuinfo/

processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 20
model           : 2
model name      : AMD E2-1800 APU with Radeon(tm) HD Graphics
stepping        : 0
microcode       : 0x500010d
cpu MHz         : 854.896
cache size      : 512 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 2
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 6
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf pni monitor ssse3 cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch ibs skinit wdt hw_pstate vmmcall arat npt lbrv svm_lock nrip_save pausefilter
bugs            : fxsave_leak sysret_ss_attrs null_seg spectre_v1 spectre_v2 spec_store_bypass
bogomips        : 3393.92
TLB size        : 1024 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate

<second processor with same information omitted>

My next thought was perhaps the other text editors do something to ask the processor to speed up? I checked the CPU Governor and it was as such:

  hardware limits: 850 MHz - 1.70 GHz
  available frequency steps:  1.70 GHz, 1.36 GHz, 850 MHz
  available cpufreq governors: performance schedutil
  current policy: frequency should be within 850 MHz and 1.70 GHz.
                  The governor "schedutil" may decide which speed to use
                  within this range.

This seemed right since /proc/cpuinfo reported the speed as 850MHz or so.... what happens when we turn on the performance governor? The clock speeds increase (somewhat - they hover around 1GHz), but micro does the same slow scrolling. 🤕

[janxkoci]

Yeah I cannot reproduce this at all - I observe no lags while scrolling the help page for example. I tried this on my laptop (elementary OS 5.1, Ubuntu-based, Tilix terminal) and over ssh connection to a CentOS7 server.

Consider closing.

[jrdek]

I'm having this same scroll-speed issue on ChromeOS 98's Linux terminal (running Debian 11 Bullseye) with 4GB RAM and an Intel Core m3, but interestingly, only locally -- SSHing into my Ubuntu 21.10 PC with 16GB RAM and an i7 3770-K does not exhibit the same issue. As with @rdrms, nano scrolls at a normal speed line-by-line.

[rdrms]

I'm having this same scroll-speed issue on ChromeOS 98's Linux terminal (running Debian 11 Bullseye) with 4GB RAM and an Intel Core m3, but interestingly, only locally -- SSHing into my Ubuntu 21.10 PC with 16GB RAM and an i7 3770-K does not exhibit the same issue. As with @rdrms, nano scrolls at a normal speed line-by-line.

Yeah I think it has to do with the processor, since I also tested locally on my laptop/server and the scrolling issue was there as well. So probably an issue on computers with either 4 or less GB of RAM and weak processors?

[janxkoci]

So probably an issue on computers with either 4 or less GB of RAM and weak processors?

Could be, I have i5 and 16GB of RAM, and the server has Intel Xeon CPU and 64GB of RAM (on the login node I used).

[janxkoci]

I just tried on my cheapish Lenovo M8 tablet and scrolling works fine there too. I use Termux for terminal and I installed micro as shown on the homepage: curl https://getmic.ro | bash. I then opened the help page and scrolled down using the Termux arrow keys. No lags.

[rdrms]

Well, the MediaTek A22Tab in the Lenovo (same in 1st and 2nd gen of the tablet) gets a Geekbench 3 score of 155 (single core) and 521 (multicore). Conversely, the AMD E2-1800 APU has a score of 141 (single core) and 244 (multicore). While the single core speed is comparable, the Lenovo benefits from being a quad core instead of dual. The Lenovo has less RAM (2gb vs 4gb) than the laptop, but the MediaTek SoC is from 2018 instead of 2012 like the AMD, so it may have faster RAM. It could also be due to the storage, the EMMC is faster than the HDD in the laptop.

Not sure, maybe if we could get more information on the M3 system that @jrdek has, might help to diagnose this.

[janxkoci]

Well I can later try and test with a very low-spec laptop I gave to my dad. It has Celeron processor (1.6GHz I think) and only 2GB of RAM. If that one doesn't lag then I don't know what will 😅

[jrdek]

The Chromebook in question is an ASUS Flip C302. Its processor is an m3-6Y30 @ 0.9GHz, with two cores; I can't quite figure out how to get Geekbench 3 running on the machine, unfortunately. It looks like it's got two 2GB LPDDR3 sticks, and the storage is eMMC.

[ElectricRCAircraftGuy]

I don't know if this is related, but I noticed Copy/Paste with Ctrl+C/V is extremely slow in micro when micro is run on a remote host over ssh. I can't taken the time to figure it out or duplicate the problem again recently though.

[janxkoci]

Oh, thanks for reminding me to test this on the low-spec Celeron machine. I just tried scrolling through the micro help page with touchpad as well as arrow keys and I see no lag whatsoever. Tested with micro 2.0.9 from Ubuntu 22.04 repos (on other machines I usually install with conda though, but here I was constrained by disk space).

The system is really low-spec:

[ElectricRCAircraftGuy]

I don't know if this is related, but I noticed Copy/Paste with Ctrl+C/V is extremely slow in micro when micro is run on a remote host over ssh. I can't taken the time to figure it out or duplicate the problem again recently though.

Update: I figured it out: How to copy/paste to/from a remote machine running micro over ssh to/from your local machine

[hebinzin]

I also have this problem when running micro over SSH, installed on a Raspberry Pi Zero W. Scrolling is really unresponsive, specially in large files.

[janxkoci]

How large files are we talking about? I really have trouble to reproduce any lag with micro, no matter if localy on low-spec HW or even over ssh (but I only have ssh access to HPCs).

[hebinzin]

Sorry for taking too long to respond. "Large files" was very subjective so I'll try to give a better picture. I'm trying to edit a file right now which has 113 lines, each of them with a few words (from one to 10, at most), and it is already getting annoyingly unresponsive. Any file that spans beyond the current window available size already starts to lag. As some here were asking to compare, nano runs fine without any lag or performance issue.
I can provide provide more specific info if you need. Just let me know how I can help and I'd be glad to.

EDIT:

I just found out that it also happens when scrolling the cursor horizontally through the line. I'm editing a file with 28 lines and, when scrolling through horizontally through a line with 67 columns it already starts to happen (when I release the arrow button, the cursor can move up to about 20 characters beyond). This file has only 364 bytes.

However, I did noticed that the issue gets worse as files get larger. In file with 12K and 429 lines, if I press the arrow key to move the cursor down 40 lines, it continues scrolling for another 60 (!) after I release the key.

[janxkoci]

Ok I just tried to test this using my longest markdown article and I observe no lag scrolling horizontally nor vertically, even on the low-spec Celeron netbook. 🤷

The file has over 650 lines and many long lines, as in markdown whole paragraphs can be on a single line.

PS: props to the devs for the Emoji support, very nice 😉

[hebinzin]

Thank you @janxkoci for giving another try.
As I see, this problem only appears in some specific scenarios, regardless of file size (as I told, I start to notice the issue in files as small as ~350 bytes). It also doesn't seem that device performance is the bottleneck per se (but it might have a influence).

Another thing I noticed is that, while the problem happens if I keep the arrow keys pressed to move around, it doesn't if I repeatedly press them to move around. In the first case, when I release the key, it takes too long to stop (as I already told you). In the second, it stops immediately when the keys are released, with no noticeable impact on scrolling.

At this point I stopped using micro with my Raspberry Pi, as this issue really prevents it from being usable. It still my first text editor in my main machine though (the same which I use to access the Raspberry Pi), where I have never experienced any issue.

[dzalf]

Same problem here on RPi B+ V1.1. I am using it in console mode only. Nano is much faster when browsing through code.

I will be opening a new issue to describe my issue.

[klauweg]

i have observed this behavior on a beaglebone. It seems to be related to my usual settings that shows git status on statusline with the status plugin. (status.branch, status.hash....). Maybe micro query the executable on every screen update? This challenge may be too much for less powerful systems.

If i disable this setting everything is fine.

I have version 2.0.8 available only. Maybe this is fixed already?