Huge input lag when browsing through code on RPi B+ v1.2 in console mode [Nano is much faster]

[dzalf]

Description of the problem or steps to reproduce

Input lag with keyboard (compared to Nano 5.4) is atrocious (nearly unusable). Simply pressing the arrow keys to navigate through the code is a painful experience with micro (which I deeply love 😢).

Specifications

Using micro 2.0.8 on a recently dusted Raspberry Pi B+ v1.2 (yes, one of the old ones) in console mode ONLY (no desktop to save resources).

Tested with the codebase from the picalc-chudnovsky repo.

Nano editor lag:

https://github.com/zyedidia/micro/assets/3759916/c123daf3-fd2b-43a3-ba17-892415294f3c

Micro editor lag (lifting my figers to show the lag after pressing arrow-down):

https://github.com/zyedidia/micro/assets/3759916/1bd2fc10-d8a6-4564-9ee2-374b36c8eb63

Commit hash: 2.0.8 OS: Raspbian 11 (Linux 6.1.21+) Terminal: Native

[dmaluka]

Using micro 2.0.8 on a recently dusted Raspberry Pi B+ v1.2 (yes, one of the old ones)

2.0.8 is one of the old ones too. :)

There is definitely a room for optimization in micro, but such a huge slowdown is suspicious.

I was going to suggest to run micro with -profile flag and look at the profiling results, but this flag is only available in recent versions, not in 2.0.8.

[dzalf]

Using micro 2.0.8 on a recently dusted Raspberry Pi B+ v1.2 (yes, one of the old ones)

2.0.8 is one of the old ones too. :)

There is definitely a room for optimization in micro, but such a huge slowdown is suspicious.

I was going to suggest to run micro with -profile flag and look at the profiling results, but this flag is only available in recent versions, not in 2.0.8.

Oh, that might be worth testing. I honestly just installed running sudo apt install micro. Perhaps the repositories from Raspbian are outdated and do not point at the latest revision.

I will update to the latest version and report back my results (in 2 years, maybe, after gcc 13.2 finishes compiling in my veteran B+ 1.2 ¬¬) #okno

Cheers

[dzalf]

Hi @dmaluka

Unfortunately, upgrading my version to the latest did not solve the issue.

I had to manually compile from source (which was particularly cumbersome as I had to install Go-taking several hours)

Any other ideas to increase performance?

[dmaluka]

I wasn't really hoping that updating to the latest version will improve performance, but the latest version has -profile command-line option, so we can try to profile it. Could you run micro -profile, use it a bit (move cursor around etc, so you can see the lag), and provide the micro.prof file which it creates in the current directory? (Or you can also try to analyze this micro.prof yourself, using go tool pprof micro.prof as described for example here: https://pkg.go.dev/runtime/pprof.)

BTW is the CPU consumption by micro very high when the lag is observed? If it's not, then maybe this profiling will not tell much, since it's rather micro waiting on some external events for too long, than consuming too many CPU cycles.

[CarlAndersson]

I experience very similar behavior on my pi zero - nano works fine but micro has high input lag. I opened a file with -profile, its attached (with additional .log extension to satisfy github's file uploader). It's a new install directly from the raspberry pi imager, only added wifi stuff and downloaded micro with getmic.ro. Let me know if there's more I can do to troubleshoot!

Versions:

• micro: 2.0.13
• Raspbian: 11 (bullseye, lite)
• RPI: Zero W 1.1

micro.prof.log

[dmaluka]

Thanks for sharing the profile. Looks like the two biggest CPU hoggers in micro on your RPi are the same as what I see on my i7-7600U. I've created issues for both:

https://github.com/zyedidia/micro/issues/3227 https://github.com/zyedidia/micro/issues/3228

Although they are not causing an actual slowdown for me (they are just causing higher CPU usage than e.g. in vim or nano, but still way below 100%), which is no wonder, due to a much more performant CPU than the BCM2835 on your RPi. (Although even if I throttle the CPU frequency down to 400 MHz I still see no lag, except some lag when quickly selecting text via mouse. But again, probably no wonder, since I still have much bigger CPU cache and so on.)

That said, I'm still not entirely sure if that is the actual cause of the lag you are seeing.

So for now I just have a couple of questions:

• Is it as bad as in @dzalf 's video, i.e. do you have this high lag even when simply moving the cursor around, without scrolling the screen?
• If you run top or htop in a separate window in parallel, then when you see the lag, do you see micro consuming nearly 100% of CPU?

[CarlAndersson]

The input lag occurs without scrolling. If I hold the right arrow down for about 5 seconds, the cursor will keep moving for an additional 5 seconds after letting go. Holding for 10 seconds gives me an additional 10 seconds after letting go. Reading in top at the same time reports around 95% cpu usage from micro. Repeating with nano gives me about 1% cpu usage.

[dmaluka]

Thanks, this is a really useful info.

If it's not too difficult, you can try to compile micro with a change I mentioned in https://github.com/zyedidia/micro/issues/3227#issuecomment-2038021696 and see if it improves anything. (I suppose it's easy: GOARCH=arm make to cross-compile it for ARM, then copy the resulting micro binary to your RPi and run it. It's a statically linked binary without dependencies, so it should run without troubles, at least in theory.)

[dmaluka]

Also a quick question just in case: if micro is running but you don't do anything in it, then top doesn't show any high CPU usage by micro, right?

[CarlAndersson]

Yep, no cpu usage from micro when I'm just idling.

[JoeKar]

I've added two comparable *.prof in #3227 from my RPi1B. The test with the map2struct still needs to be done.