How to improve speed or make it faster?

[Max87153]

I've noticed Clink it's quite slow if you type fast, or you move up the history fast. I'm kind of a fast typer so this is a kind of problem to me.
PS: i've tried recording a video where this happens but the video seems normal, no struggling

[chrisant996]

That's interesting! Thanks for reporting this.

I don't experience that, so I have some questions to help troubleshoot what's happening:

• How old is the computer, and/or what speed is the CPU?
• Does the problem go away if you run clink set autosuggest.enable false
• Does the problem go away if you run clink set clink.colorize_input false
• What is the output from set path
• Do you have additional Lua scripts installed? Custom scripts or collections of scripts such as from the clink-completions or clink-gizmos repos or other script collections?
• Do you use oh-my-posh, and is the delay mainly after pressing Space?

[Max87153]

Autosuggest seems to have unlagged it a bit, but now it doesn't auto complete haha.
Colorize fixed it too, probably I had too many things opened.
setpath returns:

PATH=C:\Program Files\Microsoft MPI\Bin\;C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v11.8\bin;C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v11.8\libnvvp;C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\intel64_win\compiler;C:\Program Files (x86)\Razer Chroma SDK\bin;C:\Program Files\Razer Chroma SDK\bin;C:\Program Files (x86)\Razer\ChromaBroadcast\bin;C:\Program Files\Razer\ChromaBroadcast\bin;C:\Program Files\Eclipse Adoptium\jdk-21.0.1.12-hotspot\bin;C:\Program Files (x86)\Common Files\Oracle\Java\javapath;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Program Files\Git\cmd;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Program Files\nodejs\;C:\Program Files\Go\bin;C:\Program Files\Mullvad VPN\resources;C:\Program Files\PuTTY\;C:\Program Files\Microsoft\Web Platform Installer\;C:\Program Files\php-8.3.0-Win32-vs16-x64;C:\Users\php\AppData\Local\Programs\Python\Python310\Scripts\;C:\Users\php\AppData\Local\Programs\Python\Python310\;C:\Users\php\AppData\Local\Microsoft\WindowsApps;C:\Users\php\AppData\Local\Programs\Microsoft VS Code\bin;C:\Users\php\AppData\Local\spicetify;C:\Users\php\AppData\Roaming\npm;C:\Users\php\go\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\WINDOWS\System32\OpenSSH\;C:\Program Files\playit_gg\bin\;C:\Program Files (x86)\Nmap;C:\Program Files (x86)\Nmap\nmap.exe;C:\Program Files\Lua;C:\Program Files\Paping;C:\Program Files\dotnet\;C:\Program Files\Cloudflare\Cloudflare WARP\;C:\Program Files (x86)\Bitvise SSH Client;C:\Program Files\NVIDIA Corporation\NVIDIA App\NvDLISR;C:\Program Files\NVIDIA Corporation\Nsight Compute 2022.3.0\;C:\Users\php\AppData\Local\NVIDIA\ChatWithRTX\env_nvd_rag\Lib\site-packages\torch\lib;C:\Users\php\scripts\;C:\Users\php\AppData\Local\Programs\Python\Python311\Scripts\;C:\Users\php\AppData\Local\Programs\Python\Python311\;C:\Users\php\scoop\shims;C:\Users\php\AppData\Local\Programs\Python\Python310\Scripts\;C:\Users\php\AppData\Local\Programs\Python\Python310\;C:\Users\php\AppData\Local\Microsoft\WindowsApps;C:\Users\php\AppData\Local\Programs\Microsoft VS Code\bin;C:\Users\php\AppData\Local\spicetify;C:\Users\php\AppData\Roaming\npm;C:\Users\php\go\bin;C:\Program Files (x86)\Nmap;C:\Program Files (x86)\Nmap\nmap.exe;C:\Users\php\AppData\Local\Microsoft\WindowsApps;C:\Program Files\Lua;C:\Program Files\Paping;C:\Users\php\AppData\Local\Programs\EmEditor;C:\Users\php\scripts\;;C:\Users\php\AppData\Local\Programs\oh-my-posh\bin
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC

I only have oh-my-posh and there is no delay when you press Space.

Here are specs:

       Et:::ztt33EEEL @Ee.,      ..,   OS: Windows 11 Pro x86_64
      ;tt:::tt333EE7 ;EEEEEEttttt33#   Host: Micro-Star International Co., Ltd. Pulse 15 B13VFK
     :Et:::zt333EEQ. $EEEEEttttt33QL   Kernel: 10.0.22631
     it::::tt333EEF @EEEEEEttttt33F    Uptime: 2 days, 11 hours, 37 mins
    ;3=*^```"*4EEV :EEEEEEttttt33@.    Packages: 4 (scoop)
    ,.=::::!t=., ` @EEEEEEtttz33QF     Shell: bash 5.2.26
   ;::::::::zt33)   "4EEEtttji3P*      Resolution: 2560x1440, 2560x1440
  :t::::::::tt33.:Z3z..  `` ,..g.      DE: Aero
  i::::::::zt33F AEEEtttt::::ztF       WM: Explorer
 ;:::::::::t33V ;EEEttttt::::t3        WM Theme: Custom
 E::::::::zt33L @EEEtttt::::z3F        CPU: 13th Gen Intel i9-13900H (20) @ 3.000GHz
{3=*^```"*4E3) ;EEEtttt:::::tZ`        GPU: Caption
             ` :EEEEtttt::::z7         GPU: NVIDIA GeForce RTX 4060 Laptop GPU
                 "VEzjt:;;z>*`         GPU: Intel(R) Iris(R) Xe Graphics
                                       GPU
                                       Memory: 28486MiB / 32471MiB

[chrisant996]

For comparison:

• Your machine is an i9-13900H with 20 effective cores at 3 GHz with 32GB RAM, and yet Clink is laggy while typing.
• My machine is an i7-10870H with 16 effective cores at 2.2 GHz with 32GB RAM, and no lag.

The PATH variable has some large directories listed twice, and that could potentially slow down autosuggest (while it collects completions), but on the other hand autosuggest is designed to run mostly asynchronously and shouldn't be interfering with typing.

It's interesting that turning off colorize cleared up the lag. That means the lag is primarily coming from running Lua scripts to parse the input line. But it looks like you said as far as you know the only Lua script you have loaded in Clink is one for oh-my-posh.

Some more troubleshooting questions:

• Have you checked the CPU usage on the computer when the lag is happening? If the CPUs are over saturated then yes it is normal to experience some lag.
• Also, what terminal program are you using?
• Have you checked if there are display driver updates available?
• Do you have ANSICON installed? If so, remove it. It has an implementation problem that degrades performance greatly (by easily around 10x to 100x). And Windows' built-in ANSI support is far more complete and functional than ANSICON's anyway (ANSICON hasn't been needed since Windows 8.1).

[chrisant996]

Here's a better question:

The system info you shared says Shell: bash 5.2.26.

Do you experience any lag when typing in bash?

I ask because here is what happens when I typed jumbled letters as quickly as my fingers can randomly hit them:

• Typing into Clink, I can observe a small bit of lag. But no lag when I type at my fullest real speed (which is around 100 wpm).
• Typing into bash running in Ubuntu, I actually observe noticeably more lag than in Clink.

This is interesting, because both Clink and bash are using Readline.

Once I realized I could reproduce a small bit of lag with ultra high speed random input, then I started doing some performance profiling, and I started disabling lots of different features that the profiler showed as using time. But no matter what I turn off, it only has an infinitesimal affect on reducing lag. And bash itself seems to have even more lag than Clink.

So I'm curious whether you experience lag in bash.

[chrisant996]

And I experience a small lag when typing into plain CMD.exe's command prompt (without Clink).

And when I added detailed logging about delays, there is a small amount of lag even when the APIs claim to be receiving input instantly when it's available. I can stop typing, and it takes another 100-200 ms for another 6 or so letters to show up one by one, and yet the logging says for each of the letters there isn't input available yet, and it has to wait for 15 to 20 milliseconds before the OS APIs have any input available -- even after I've completely stopped typing, the input APIs still experience waits before the input I already finished typing actually becomes available. That particular delay is happening in something lower-level than Clink.

The lag that I'm experiencing seems to have nothing to do with Clink. I experience it in Windows Terminal, in ConEmu, in mintty, and in the old default conhost (standalone legacy default console windows), regardless whether Clink is present or not.

I'm not sure what's going on here, but the lag I'm able to experience seems to be independent from Clink.
I don't know how to tell whether the lag I'm experiencing is the same as the lag you're experiencing.

So I'm also curious what terminal you're using.

[Amueller36]

I did not particularly experience any lag, but I just saw this issue and recently I have seen a Video that mentioned the slow windows console layer and a way on "bypassing the windows console layer", maybe this is of interest for you:

https://youtu.be/hxM8QmyZXtg?t=1155

Thanks for your great work btw, I really enjoy the clink experience! :)

[chrisant996]

That's an interesting video, thanks for sharing it. It's about a very different issue than input lag. I'm not seeing output lag (performance measurements confirm I'm not experiencing output lag or slow output). Instead I'm seeing a tiny amount of input lag when hammering keys at around 200 wpm. And I think that's the same thing you're hitting. It's not output that's slow. The console input APIs are saying input isn't available for a few milliseconds even when multiple keys are queued already. That's where the slowness is coming from.

Re: the video, it's worth noting there's a lot of criticism in the video, but also a lot of "I don't know what it's doing and why it's slow" combined with "my code handles everything ... except for the following things which are really the hard parts". Which feels odd, because yeah if one removes all the code that handles all the hard stuff, then it's going to be faster. He's got some interesting points. But he claims it's an apples to apples comparison, and that doesn't seem accurate.

And the super fast mode seems to disable ANSI escape code handling and colors and all that kind of stuff. I wonder whether the author hasn't gotten to thinking through all the things that the "terrible and slow" code is actually taking care of.

Anyway, (1) Clink can't make use of that and (2) that stuff doesn't seem to be related to the issue here.