[WSL2] input delay

[jmederosalvarado]

ble version: 0.4.0-devel3+0506df2
Bash version: 5.0.17(1)-release, x86_64-pc-linux-gnu

Hi. This project is great.

Basically I'm having performance issues, there is a perceptible delay between my key strokes and the letter appearing on the screen. Is this something that should be expected ? I'm currently under Ubuntu 20.04 on WSL2. I'm coming from zsh and I would really love to use bash, but syntax-hightlight and autocomplete features like the ones you provide are a must have. However performance issues are a deal breaker.

I see there are other open issues related to performance, but I saw they were more specifically related to autocomplete or some other features. Please let me know if I should close this and continue the discussion in those open issues.

---

Summary

(Edited by @akinomyoga)

Here I summarize the discussions made here. There can be various causes that slows down the response in WSL2. Depending on the actual bottleneck in your environment, maybe you can take the following workarounds.

Remove slow Windows filesystems on /mnt from PATH

It is known that the Windows filesystems mounted on /mnt is very slow microsoft/WSL#4197. When PATH contains directories under /mnt, the completion becomes slow. One solution is to remove /mnt/* from the environment variable PATH:

From #96 (comment)

If you are fine with removing all the Windows paths from PATH, you can just put the following command in your blerc:

ble/path#remove-glob PATH '/mnt/*'

Another solution is to configure wsl so that it doesn't include Windows paths in the environment variable on the startup of the shell:

From #96 (comment)

You can also create a file called /etc/wsl.conf and put this:

[interop]
appendWindowsPath = false

More info can be found in WSL's docs here.

Integration with bash-preexec to remove the overhead of DEBUG trap

This has been solved by introducing a proper support for the integration of ble.sh and bash-preexec. When bash-preexec is loaded, ble.sh automatically detects it and properly communicate with the loaded bash-preexec. Please just update ble.sh to the latest master. See also #96 (comment).

Disable auto-complete

If the above settings does not work, maybe you can turn off auto-complete or set a delay for auto-complete.

From #96 (comment)

$ bleopt complete_auto_complete=

[...] you can configure bleopt complete_auto_delay (the delay of auto-complete) so as to reduce the frequency of auto-complete, e.g.,

# blerc
bleopt complete_auto_delay=300

[akinomyoga]

Thank you. OK, I have set up WSL2 with Ubuntu 20.04 LTS and could reproduce the small delay even after disabling auto-complete (although the delay is almost unnoticeable in my environment). It seems that the plain Bash doesn't have the delay in WSL2. I don't see the delay either in Cygwin or genuine Linux systems. This must be related to some characteristics of WSL2.

I'll take a look later, but I'm busy recently so would appreciate it if you could narrow down the bottleneck. Thank you!

[jmederosalvarado]

I kind of narrowed it down. It turns out the delay only happens (or at at least is most noticeable) when I type the very first character after starting my terminal session, subsequent keystrokes appear to behave normal. In addition this only happens when I override some settings in the blerc file. Particularly I'm changing the syntax highlight colors, so my blerc file only contains a bunch of calls to ble-color-setface. Please let me know if this makes sense.

[akinomyoga]

It turns out the delay only happens (or at at least is most noticeable) when I type the very first character after starting my terminal session,

I'm not sure, but this is possibly related to auto-complete. Is the delay still present after disabling auto-complete by the following command?

$ bleopt complete_auto_complete=

If it is the delay by auto-complete, you can configure bleopt complete_auto_delay (the delay of auto-complete) so as to reduce the frequency of auto-complete, e.g.,

# blerc
bleopt complete_auto_delay=300

In addition this only happens when I override some settings in the blerc file. Particularly I'm changing the syntax highlight colors, so my blerc file only contains a bunch of calls to ble-color-setface.

Ah, OK. ble.sh defers the initialization of faces until it is first required. It seems the deferred settings of faces takes some time in your environment. I'll check it later.

[jmederosalvarado]

Oh I see. If ble.sh defers the initialization of faces until it is first required, then that would explain the problem. There are a lot of calls to ble-color-setface in my blerc file, so if they are all run once I type for the first time, we should expect the delay. Is there any way to tweak tis behaviour, maybe some kind of flag or config to make ble.sh evaluate calls to ble-color-setface when blerc file is sourced ????

[rashil2000]

Hi @akinomyoga!

I was about to open an issue related to performance in WSL2, but I saw that this is already open. I'm facing issues too. I'll try to elaborate.

While auto-complete and auto-suggestions work fine, there's a very perceptible lag on input (delay between typing and characters appearing). I'm on a laptop, so power consumption might be interfering with how snappy the input is. Therefore I've tried to record on both battery-mode and plugged-in mode.

battery

plugged-in

Both these have very perceptible lag, but the typing is slightly more responsive in plugged-in mode. I have only 3 lines in my blerc

bleopt history_share=1                                                                    
ble-bind -f up 'history-search-backward hide-status:immediate-accept:point=end'           
ble-bind -f down 'history-search-forward hide-status:immediate-accept:point=end'

Note that this lag doesn't appear in WSL2 at all (whether on battery or plugged-in) in zsh, pwsh or vanilla bash.

[akinomyoga]

@rashil2000 Thank you for the information!

First, I need to note that ble.sh is different from the normal line editors of the shells which are implemented in the compiler languages such as C and C#, so the performance difference is inevitable. In particular, when the computer is slow, there might be nothing that we can do. Nevertheless, if you could point out the bottleneck of ble.sh, I'm not reluctant to improve it, but generally, performance issues wouldn't be completely resolved in slow computers as far as ble.sh is implemented in Bash script.

In your case, I'm not sure if there is any bottleneck that significantly worsens the performance, or just the entire processing takes a long time in the battery mode, but I might do something in the former case. I implemented ble.sh so that the auto-complete doesn't interfere with the user input processing, so there are two possibilities: 1) the bottleneck lies outside of auto-complete, or 2) the user-input detection becomes slow in the battery mode. I have related questions:

• Q1: What are the results of the following command in the battery mode and the plugged-in mode?

$ ble-measure -a 50 'ble/util/msleep 10

• Q2: When you turn off auto-complete and other background processing, does the response in the battery mode change?

$ bleopt complete_auto_complete=
$ bleopt complete_menu_filter=
$ bleopt complete_auto_menu=

• Q3: With the following settings In addition to the above settings, does the response in the battery mode change?

$ bleopt highlight_filename=
$ bleopt highlight_variable=

[rashil2000]

...performance issues wouldn't be completely resolved in slow computers as far as ble.sh is implemented in Bash script.

I have a gaming laptop [Specs: i7-8750H, 6 cores (12 threads), 16GB RAM, GTX 1060 GB graphics]. I don't think the system is a slow one. In any case, to completely eliminate any possibility of doubt, I conducted an elaborate experiment. I created 2 virtual machines, both running Ubuntu:

• one running inside VMware on my own laptop (2 cores, 4GB RAM alloted)
• one running on Azure (1 core, 1GB RAM alloted)

In both these VMs, ble.sh runs buttery smooth - no input lag/latency. Note that they're not particularly heavily-specced VMs. This leads me to believe that the performance is certainly not a ble.sh issue. It almost exclusively occurs on WSL (and sometimes MSYS2, or even Termux (Android)). However, the amazing features of ble.sh have spoilt me, and I would like to use it everywhere possible (which includes WSL2, albeit with some workarounds, if possible).

• Q1: What are the results of the following command in the battery mode and the plugged-in mode?

10435.150 usec/eval: ble/util/msleep 10 (x10) # battery
10111.150 usec/eval: ble/util/msleep 10 (x10) # plugged-in

• Q2: When you turn off auto-complete and other background processing, does the response in the battery mode change?

No effect

• Q3: With the following settings In addition to the above settings, does the response in the battery mode change?

Very slight improvement

[akinomyoga]

Thanks for the information and answers. From these answers, it seems that the delay is caused by somewhere not related to the auto-complete or syntax-highlighting based on the filenames. Another possibility that causes the delay is the access to /tmp which is a RAM disk on many Linux distributions but is not in WSL2 by default.

• Q4: What are the result of the following command in the battery and plugged-in modes respectively.

$ ble-measure -a 5 'ble/util/assign a "echo $((b++))"'

I have also tested with WSL2 in my environment. It seems that I also have a very small delay with WSL2 (though I'm not sure if this is the same issue as the one that you observe). I tried to figure out the cause of the small delay, but I found some strange behavior: While I observe the delay when I open the WLS2 through the "Ubuntu 20.04 LTS" icon in the Windows start menu, it seems that I don't have the delay if I connect to the WSL2 through ssh from Cygwin.

The terminal that opens up by the start menu icon seems to be actually the command prompt (at least the property window which can be opened from the shortcut menu of the window icon is that of the command prompt). Maybe the delay is related to the terminal or some interface of the connection between the WSL2 subsystem and the Windows subsystem.

• Q5: Which terminal do you use for WSL2? Or, how do you connect to WSL2?
• Q6: If you connect to the WSL2 using ssh, do you experience the same delay in the battery mode?

[rashil2000]

• Q4: What are the result of the following command in the battery and plugged-in modes respectively.

1314.331 usec/eval: ble/util/assign a "echo $((b++))" (x100) # battery
 827.690 usec/eval: ble/util/assign a "echo $((b++))" (x100) # plugged-in

• Q5: Which terminal do you use for WSL2? Or, how do you connect to WSL2?

I start it using the wsl command. This is the same command that the Start menu shortcut uses. It is the recommended way of starting/stopping/managing WSL distributions.

• Q6: If you connect to the WSL2 using ssh, do you experience the same delay in the battery mode?

I don't have Cygwin set up on my machine, but I could install openssh on MSYS2 (pacman -S openssh). But since Windows 10 already comes with the OpenSSH client pre-installed (at C:\Windows\System32\OpenSSH\ssh.exe), I used that. Surprisingly, I experience zero input lag as you described, even on battery mode. Ble.sh runs buttery-smooth.

It's definitely an issue with the wsl command. However, there are a few points to note:

1. WSL2 does not support systemd services. As such, the ssh daemon will have to be started manually each time a distro is started.
2. WSL2's network configuration is NAT'd, which means the IP address will change every time WSL2 is restarted. There are ways around it, but they're not pretty. Would love to hear what method you use to get around this.
3. When using the wsl command, Windows sets up some useful variables inside the WSL2 shell, like these:

WSL_DISTRO_NAME=arch-linux
WSL_INTEROP=/run/WSL/4145_interop

They are particularly useful for detecting if you're on WSL for generic linux apps/scripts. When using ssh, they don't get set.

[rashil2000]

Needless to say, the disparity between wsl and ssh is huge (although ble.sh is the first application where I've observed this).

Do you think I should report this in the official WSL repo (citing this issue as source)?

[akinomyoga]

OK, thank you for your information. As you have experienced the zero delay with ssh, the delay that I observe in my system seems to be the same issue with yours. I'm not sure if we can do anything from the ble.sh side, but as readline and Zsh Line Editor don't share the issue, maybe some specific operation that ble.sh uses is slow with the wsl connection. I will later test it in my environment.

Do you think I should report this in the official WSL repo (citing this issue as source)?

Currently, the issue is not so clear, and I think they are so busy that they don't have time to investigate such an obscure issue that "some specific application is slow in some specific situation". I'd think the issue would be just ignored at best (unless there are reports from many different people on the same issue with ble.sh which is not likely).

We may report it only after we have identified what specific operation causes the delay of wsl.

[rashil2000]

We may report it only after we have identified what specific operation causes the delay of wsl.

Okay, I understand that.

Thank you for your help so far and the ssh tip!