-
-
Notifications
You must be signed in to change notification settings - Fork 573
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Delay when running WSL bash shell #1323
Comments
Delay before each prompt? |
No, the delay is before the first prompt only. |
Cmd and PowerShell do not have the same delays |
When exactly the diary occurs? Video? |
On the status bar, the delay is before wslbridge.exe[65]:18816 is displayed. The text says conemu-cyg-64.exe. This is when you open a new tab. The delay is before you see the first prompt. Running wsl produces an instant prompt. |
I am not sure how to record a video. |
Try to add |
Can confirm that this is happening. Although it has been happening for me for as long as I can remember. |
Here is the log:
The delay is occurring AFTER the last line is visible on the screen. |
@Habitats I cannot be certain that the Windows update caused this. It may have been an update to ConEmu or some other change. But it started at the same time. |
Try to monitor process creation. The lag occurs on certain step, but outside of ConEmu code. |
I tried ProcessMonitor, but the hole in the timings appears random :( There is way too much data for me to see anything without something to look for. I have the feeling that wslbridge is struggling with something, but I cant see anything that can help. I ran the command you gave and I didn't see anything out of the ordinary. Does it write a log somewhere? I tried looking here |
Try to filter ProcessMonitor logs by "operation contains process". That is the start point. LogFiles on the desktop. Did you tried official wslbridge without ConEmu? AFAIK there is a bundle with mintty. |
Process monitor: I used Official wslbridge: back when I enabled it, I downloaded it manually and followed the instructions on your website. I could try downloading it again and modify the task's parameters to use that. The delay may have started appearing when you bundled the files. I install every alpha release that came as an update. Logs going to do that now and post back. |
ConEmu-gui-12108.log There are the logs. I used |
I downloaded wslbridge from here https://github.com/rprichard/wslbridge/releases and the installed wsltty, and then compared the two files, they seem identical. Then copied the bundled cygwin1.dll to wsl2 folder (along with wslbridge.dll and wslbridge-backend) and changed the task as follows: |
Yes, I don't have any delay. What about wsltty, did you check it as I asked? BTW, do you have git or cygwin installed on your computer? |
I installed wsltty and there is also a delay there, but not as much (maybe 1-2 seconds vs 3-4 with ConEmu). I have Visual Studio 2017 and git installed. Not sure about C++ tools, but I could install them if needed. I haven't installed Cygwin, I am not sure what to do with it. What do you want me to do? |
What about It looks like the delay occurs after connector runs VisualStudio is not useful to debug cygwin applications. I've asked about cygwin because it's interesting to compare startup time of wsl and bash from cygwin. |
@BladeMF Did you install the Windows Store version of Ubuntu? |
No, I used windows Add/Remove Features (before it was in the store) and upgraded it. |
@Maximus5 wsl.exe is instant. |
@rprichard Do you have any idea what to test further? |
@Maximus5, I just noticed something. When a new console is opened, it ends up waiting with a text like "wslbridge.exe[64]:some number". The moment the prompt appears, the "some number" changes to some other number. Is that a port or a process id? |
Process id
|
So why does it change?
|
Because the process is changed? |
Same here. Worked fine with no delays on my old laptop with Ubuntu 14.04 WSL and not sure what version (i guess June release) of ConEmu. Now, on 16.04 or 18.04 and latest ConEmu even something like nano takes 2 redraws and a second or two to exit, initiating ssh connections is slower and so on. Maybe there's a way to install Ubuntu 14.04 on WSL? |
@meatuses : What's differece between |
Wsl has different supported switches |
@Maximus5 : Can you elaborate? I'm using bash.exe and looking for better one to use as main terminal. |
Better for what? |
I see, I have only one p/s: I use |
@Maximus5 It seems that the latest update of Windows 10 includes a public ConPTY API. Is it enough to replace wslbridge? Are you going to use this API in the near future? |
It seems delays on vim/htop/less/etc. are proportional to buffer height in conemu settings. Reducing buffer height lowers delays. |
I can confirm that lowering the buffer height does indeed lower the delay but it's still quite noticeable even with the buffer as low as one hundred. Edit: This is still present in the latest build 190108 |
I want to say that I have the same issue. mc start times: |
May be this issue is related to gh-1841 |
I'm also having this problem. Some additional notes:
This leads me to believe that the problem might be in some sort of application state/history, which is not stored in ConEmu.xml. @Maximus5 - does anything come to mind? For me, the delay is most noticeable when starting/exiting less or vim. Can you explain gh-1841? I'm not familiar enough with the architecture of ConEmu, or these apis to know what alternate and primary scrollback buffers are, but given that vim and less both enter what seem to me like different scrolling/history modes (sorry, I'm a laymen when it comes to terminal programming :)), it seems like you're right - it could be related... |
@kbirger Are you definite about same command lines for wsl task in Cmder and ConEmu instances? Just to be sure that they both run wsl via connector? Have they both same height of the buffer? I hope so, than there are some Windows options that ConEmu doesn't control. |
@Maximus5 wow. interesting. I loaded Cmder back up, and now I am experiencing the same issue, regardless of whether I reset the settings on it. I did as you said, and...
It seems that this buffer height has some bearing on the delay. If I set it to a smaller value, the delay disappears! I suspect that this value is tied to Settings > General > Size & Pos > [Console buffer height] |
If you are experiencing the same delay in both instances - no sense in comparing properties. |
I get what you're saying. I was initially not experiencing the same issue, so I decided to eliminate any potential variables. I tried what you suggested above, and I get the same issue in the new folder. What's the downside to decreasing the buffer size? Inability to scroll as far back? The issue seems to be a concert of wslbridge/connector + switching buffers + buffer size edit: value of 1000 seems to be OK. |
Please try 190310.
|
I'm seeing no noticeable delay with minimal testing. |
I tested 190310 and the issue seems gone. Thank you! |
Seems better on the new build, but not in all cases. My original test of entering/exiting vim and less seems good, but I'm noticing a lot of lag on shell completion (using zsh personally, with the multi-choice completion) compared to setting the buffer size / Long console output setting to a lower value. |
@kbirger Shell completion is not related to alternative buffer, it operates in primary buffer only. Another issue. |
For me oh-my-zsh was the biggest culprit. For some reason the Console buffer height under General > Size & Pos > Console buffer height was set for 32767 which is egregious, so I lowered that to 1000. Lowering the console buffer height size made it a bit faster, but what really sped it up for me was using bash instead of oh-my-zsh. The theme I was using in oh-my-zsh was 'muse' which is a pretty minimal one, but I know most of these themes mess with the $PS1 variable to do fancy prompt things. Kinda bummed I can't run zsh but not bummed enough to endure the lag it induces. Hope this helps someone. |
Versions
ConEmu build: 171117 x64
OS version: Windows 1709 x64
Used shell version (Far Manager, git-bash, cmd, powershell, cygwin, whatever): bash
Problem description
When starting the Bash task, there is a 4-5 seconds delay before the command prompt being shown. This started after the Windows update to 1709.
Task definition is:
set "PATH=%ConEmuBaseDirShort%\wsl;%PATH%" & %ConEmuBaseDirShort%\conemu-cyg-64.exe --wsl -cur_console:pm:/mnt
Steps to reproduce
Actual results
Delay in showing the command prompt.
Expected results
No delay.
The text was updated successfully, but these errors were encountered: