Terminal gets extremely sluggish after a day of use #10728

@zadjii-msft commented on GitHub (Oct 23, 2020):

Yep, that one

@zadjii-msft commented on GitHub (Oct 23, 2020): ![image](https://user-images.githubusercontent.com/18356694/97019292-c5164680-1515-11eb-9781-562150353815.png) Yep, that one

claunia commented

@lminer commented on GitHub (Oct 23, 2020):

How do I send it to you? The files are big

@lminer commented on GitHub (Oct 23, 2020): How do I send it to you? The files are big

claunia commented

@alexandermalfait commented on GitHub (Oct 26, 2020):

@zadjii-msft , you can download a dump file and a video showing the issue from this link: https://we.tl/t-Q9SG7e5z6r

Note that the dump file is 1GB uncompressed, which is a lot of memory usage for a terminal.

In task manager, I could see 700MB of memory usage, dropping to 70MB after restarting the terminal.

@alexandermalfait commented on GitHub (Oct 26, 2020): @zadjii-msft , you can download a dump file and a video showing the issue from this link: https://we.tl/t-Q9SG7e5z6r Note that the dump file is 1GB uncompressed, which is a lot of memory usage for a terminal. In task manager, I could see 700MB of memory usage, dropping to 70MB after restarting the terminal.

claunia commented

@mehgcap commented on GitHub (Oct 26, 2020):

@zadjii-msft I can only get this to happen reliably when SSH-ed into a few work servers. In case the dump file contains potentially sensitive data, is there an email address where I can send it?

@mehgcap commented on GitHub (Oct 26, 2020): @zadjii-msft I can only get this to happen reliably when SSH-ed into a few work servers. In case the dump file contains potentially sensitive data, is there an email address where I can send it?

claunia commented

@djsavvy commented on GitHub (Oct 29, 2020):

@mehgcap see https://github.com/microsoft/terminal/issues/7981 -- @DHowett provided an e-mail where you can send a dump.

@djsavvy commented on GitHub (Oct 29, 2020): @mehgcap see https://github.com/microsoft/terminal/issues/7981 -- @DHowett provided an e-mail where you can send a dump.

claunia commented

@rebane2001 commented on GitHub (Oct 30, 2020):

I can confirm it as well, here's a GIF of me typing a sentence in a Windows Terminal vs just WSL

Usually, when using the Windows Terminal, I have a SSH session through WSL into a tmux session on a server. This server probably prints over a million lines of text a day, so my gut tells me that this data somehow gets stored in a cache/history of some sort that gets laggy once large enough. Of note is also that tmux sends a lot more data than a simple SSH session due to how it works. However, closing tabs does not solve this issue, I need to restart Windows Terminal for it to run fast again.

@rebane2001 commented on GitHub (Oct 30, 2020): I can confirm it as well, here's a GIF of me typing a sentence in a Windows Terminal vs just WSL ![2020-10-30_22-26-22](https://user-images.githubusercontent.com/6316541/97753761-f8049f80-1afe-11eb-9021-b508e2f0afd5.gif) Usually, when using the Windows Terminal, I have a SSH session through WSL into a tmux session on a server. This server probably prints over a million lines of text a day, so my gut tells me that this data somehow gets stored in a cache/history of some sort that gets laggy once large enough. Of note is also that tmux sends a lot more data than a simple SSH session due to how it works. However, closing tabs does not solve this issue, I need to restart Windows Terminal for it to run fast again.

claunia commented

@alexandermalfait commented on GitHub (Nov 9, 2020):

I've just had a (long overdue) 4 day holiday.

Coming back to my desktop session, Windows Terminal was extremely slow.
So the issue seems to "build up" even when WT is not being used at all.

@alexandermalfait commented on GitHub (Nov 9, 2020): I've just had a (long overdue) 4 day holiday. Coming back to my desktop session, Windows Terminal was extremely slow. So the issue seems to "build up" even when WT is not being used at all.

claunia commented

@stedaniels commented on GitHub (Nov 30, 2020):

I get this consistently as well, and have for months. I know I shouldn't be leaving terminal windows open over night, but it really shouldn't be a problem either :-) This seems to happen on multiple unrelated Windows 10 installs. E.g. a work AD joined workstation and also my personal Dell PC, and personal homebuilt 7 year old PC.
Do you need any further dumps sending to you?
I'm pretty sure if I just open Windows terminal on a Friday evening, and attempt to use it on a Monday morning (wishful thinking) then the issue would also be present.
Cheers,
Steve

@stedaniels commented on GitHub (Nov 30, 2020): I get this consistently as well, and have for months. I know I shouldn't be leaving terminal windows open over night, but it really shouldn't be a problem either :-) This seems to happen on multiple unrelated Windows 10 installs. E.g. a work AD joined workstation and also my personal Dell PC, and personal homebuilt 7 year old PC. Do you need any further dumps sending to you? I'm pretty sure if I just open Windows terminal on a Friday evening, and attempt to use it on a Monday morning (wishful thinking) then the issue would also be present. Cheers, Steve

claunia commented

@RoyLi-Pvt commented on GitHub (Dec 3, 2020):

I have same problem

@RoyLi-Pvt commented on GitHub (Dec 3, 2020): I have same problem

claunia commented

@kyuyeonpooh commented on GitHub (Dec 4, 2020):

I also have the same problem.

@kyuyeonpooh commented on GitHub (Dec 4, 2020): I also have the same problem.

claunia commented

@NeilMacMullen commented on GitHub (Dec 23, 2020):

I consistently see this issue (raised as #8640 above) on a machine we use to run some production scripts. Will report further findings here.

@NeilMacMullen commented on GitHub (Dec 23, 2020): I consistently see this issue (raised as #8640 above) on a machine we use to run some production scripts. Will report further findings here.

claunia commented

@MikeRixWolfe commented on GitHub (Jan 2, 2021):

Same issue in both 1.4 release and 1.5 prerelease with WSL1 (Ubuntu 18.04) on my Kaby Lake era desktop build. The issue seems to occur after a few days, closing the terminal (which itself takes up to 10 seconds sometimes) and reopening it fixes the issue. I leave a terminal open constantly (with constant irssi activity).

Edit: because it was brought up below, my terminal usage is also single tab with an ssh+tmux session

@MikeRixWolfe commented on GitHub (Jan 2, 2021): Same issue in both 1.4 release and 1.5 prerelease with WSL1 (Ubuntu 18.04) on my Kaby Lake era desktop build. The issue seems to occur after a few days, closing the terminal (which itself takes up to 10 seconds sometimes) and reopening it fixes the issue. I leave a terminal open constantly (with constant irssi activity). Edit: because it was brought up below, my terminal usage is also single tab with an ssh+tmux session

claunia commented

@kyuyeonpooh commented on GitHub (Jan 2, 2021):

I found that no issue occurs when using terminal with only single tab. I have opened a single-tab terminal for 2 weeks, but no speed problem found while opening new tab or tab switching. Opening multi-tab terminal for a long time may be the cause of this issue.

@kyuyeonpooh commented on GitHub (Jan 2, 2021): I found that **no issue occurs when using terminal with only single tab**. I have opened a single-tab terminal for 2 weeks, but no speed problem found while opening new tab or tab switching. **Opening multi-tab terminal for a long time** may be the cause of this issue.

claunia commented

@Blaok commented on GitHub (Jan 2, 2021):

I found that no issue occurs when using terminal with only single tab. I have opened a single-tab terminal for 2 weeks, but no speed problem found while opening new tab or tab switching. Opening multi-tab terminal for a long time may be the cause of this issue.

My experience is that keeping a single tab only makes the problem shows up slower. After a couple of days it still becomes sluggish when I try to copy from the terminal. My workaround now is to keep a single terminal tab, launch a tmux server in WSL, switch sessions in tmux, and restart the terminal when it's sluggish.

@Blaok commented on GitHub (Jan 2, 2021): > I found that **no issue occurs when using terminal with only single tab**. I have opened a single-tab terminal for 2 weeks, but no speed problem found while opening new tab or tab switching. **Opening multi-tab terminal for a long time** may be the cause of this issue. My experience is that keeping a single tab only makes the problem shows up slower. After a couple of days it still becomes sluggish when I try to copy from the terminal. My workaround now is to keep a single terminal tab, launch a tmux server in WSL, switch sessions in tmux, and restart the terminal when it's sluggish.

claunia commented

@Don-Vito commented on GitHub (Jan 5, 2021):

As @yakobyd mentioned here https://github.com/microsoft/terminal/issues/8702#issuecomment-754303204, the problem seems to reproduce consistently with ssh+tmux. His observation that can be relevant was that:

When printing a large text file during a tmux session, the memory consumption of the terminal process doubles (60MB -> 120MB). After closing the tmux session, and clearing the terminal, there is no way to access the printed text. However, the memory of the terminal process does not clear.

@Don-Vito commented on GitHub (Jan 5, 2021): As @yakobyd mentioned here https://github.com/microsoft/terminal/issues/8702#issuecomment-754303204, the problem seems to reproduce consistently with ssh+tmux. His observation that can be relevant was that: >When printing a large text file during a tmux session, the memory consumption of the terminal process doubles (60MB -> 120MB). After closing the tmux session, and clearing the terminal, there is no way to access the printed text. However, the memory of the terminal process does not clear.

claunia commented

@stedaniels commented on GitHub (Jan 10, 2021):

I didn't mention it at the time, but I use tmux heavily. It seems to be a common theme?

@stedaniels commented on GitHub (Jan 10, 2021): I didn't mention it at the time, but I use tmux heavily. It seems to be a common theme?

claunia commented

@mehgcap commented on GitHub (Jan 10, 2021):

Just for the record, I do not use TMUX or any other multi-window solution in my terminal work. I sometimes ctrl-z something and use fg to get back to it, but even that is pretty rare. That's as far as I go into having multiple things going at once in the same session. I tend to pop open a new terminal and get into the same server if I need to do multiple things on one host.

@mehgcap commented on GitHub (Jan 10, 2021): Just for the record, I do *not* use TMUX or any other multi-window solution in my terminal work. I sometimes ctrl-z something and use fg to get back to it, but even that is pretty rare. That's as far as I go into having multiple things going at once in the same session. I tend to pop open a new terminal and get into the same server if I need to do multiple things on one host.

claunia commented

@djsavvy commented on GitHub (Jan 22, 2021):

Interestingly, I haven't been able to reproduce this over the last couple of weeks. I've left my terminal session open (connected to ssh/tmux/mosh) for several days, and switching tabs/typing is still snappy.

I'm on the latest Windows Terminal Preview.

Is it possible that a Windows update fixed this for me? I'm on the latest insider dev build.

@djsavvy commented on GitHub (Jan 22, 2021): Interestingly, I haven't been able to reproduce this over the last couple of weeks. I've left my terminal session open (connected to ssh/tmux/mosh) for several days, and switching tabs/typing is still snappy. I'm on the latest Windows Terminal Preview. Is it possible that a Windows update fixed this for me? I'm on the latest insider dev build.

claunia commented

@JohnLukeBentley commented on GitHub (Jan 24, 2021):

Windows terminal is extremly sluggish/slow for me too. As for @stedaniels I've had this behaviour for months.

Unlike others the sluggishness comes on quickly. From opening Windows Terminal I try to type (each character individually, without using autocomplete) and execute the powershell command Get-ChildItem | Format-Table -Autosize repeatedly. By the third iteration it's unbearably slow. At this point WT is unuseable.

I'm on WT Version 1.4.3243.0. Using Powershell 7.1.1 (64 bit), installed from an msi. Sluggishness also occured with Powershell installed via the MS Store (which I presume was also 64 bit).

A random stab in the dark at an interaction causing the problem: Is the 64 bit version of Powershell causing the slowdown? Before I get around to testing this myself perhaps anybody else can say whether their sluggishness in WT exists with a 32 bit Powershell install.

Edit: I'm on Windows 10. 19042.746.

@JohnLukeBentley commented on GitHub (Jan 24, 2021): Windows terminal is extremly sluggish/slow for me too. As for @stedaniels I've had this behaviour for months. Unlike others the sluggishness comes on quickly. From opening Windows Terminal I try to type (each character individually, without using autocomplete) and execute the powershell command `Get-ChildItem | Format-Table -Autosize` repeatedly. By the third iteration it's unbearably slow. At this point WT is unuseable. I'm on WT Version 1.4.3243.0. Using Powershell 7.1.1 (64 bit), installed from an msi. Sluggishness also occured with Powershell installed via the MS Store (which I presume was also 64 bit). A random stab in the dark at an interaction causing the problem: Is the 64 bit version of Powershell causing the slowdown? Before I get around to testing this myself perhaps anybody else can say whether their sluggishness in WT exists with a 32 bit Powershell install. Edit: I'm on Windows 10. 19042.746.

claunia commented

@RoyLi-Pvt commented on GitHub (Jan 26, 2021):

7Tabs 3SSH&TMUX 24Hours no lag on input but tab switch and exit is very slow~

Win10 64Bit 20H2 19042.746

@RoyLi-Pvt commented on GitHub (Jan 26, 2021): 7Tabs 3SSH&TMUX 24Hours no lag on input but tab switch and exit is very slow~ Win10 64Bit 20H2 19042.746

claunia commented

2026-01-31 02:28:43 +00:00

@JohnLukeBentley commented on GitHub (Jan 29, 2021):

I've just uninstalled Powershell 64bit (7.1.1) and Installed Powershell 32bit (7.2.0-Preview 2). On repeat of my previous steps, typing out in full and executing Get-ChildItem | Format-Table -Autosize three times, none of the sluggishness of Windows Terminal exists. Ctrl+Tabbing between tabs is smooth and fast.

I then uninstalled Powershell 32bit (7.2.0-Preview 2) and installed Powershell 32bit (7.1.1). I repeated the same tests. The sluggishness was also absent.

This was only an test of sluggishness on immediately opening Windows Terminal. I'll try leaving Windows Terminal open for a day to see if I get any of the sluggishness others report.

So, at this point, it would seem the interacting cause (for immediate sluggishness at least) is the 64bit version of powershell (plus some additional factor or factors). The (temporary) workaround is to use the 32bit version (e.g. from https://github.com/PowerShell/PowerShell/releases > Some release > Assests > PowerShell-7.1.1-win-x86.msi ).

@lminer, and others, does your sluggisness (appearing only after some while) with Windows Terminal exist with a Powershell 32bit version installed (and with Powershell 64bit removed)?

@JohnLukeBentley commented on GitHub (Jan 29, 2021): I've just uninstalled Powershell 64bit (7.1.1) and Installed Powershell 32bit (7.2.0-Preview 2). On repeat of my previous steps, typing out in full and executing `Get-ChildItem | Format-Table -Autosize` three times, none of the sluggishness of Windows Terminal exists. Ctrl+Tabbing between tabs is smooth and fast. I then uninstalled Powershell 32bit (7.2.0-Preview 2) and installed Powershell 32bit (7.1.1). I repeated the same tests. The sluggishness was also absent. This was only an test of sluggishness on immediately opening Windows Terminal. I'll try leaving Windows Terminal open for a day to see if I get any of the sluggishness others report. So, at this point, it would seem the interacting cause (for immediate sluggishness at least) is the 64bit version of powershell (plus some additional factor or factors). The (temporary) workaround is to use the 32bit version (e.g. from https://github.com/PowerShell/PowerShell/releases > Some release > Assests > PowerShell-7.1.1-win-x86.msi ). @lminer, and others, does your sluggisness (appearing only after some while) with Windows Terminal exist with a Powershell 32bit version installed (and with Powershell 64bit removed)?

claunia commented

@rebane2001 commented on GitHub (Jan 29, 2021):

The 64bit PowerShell issue is probably separate from what others have been experiencing as I have this problem all the time with just WSL and not PowerShell. I also couldn't reproduce the PowerShell sluggishness.

@rebane2001 commented on GitHub (Jan 29, 2021): The 64bit PowerShell issue is probably separate from what others have been experiencing as I have this problem all the time with just WSL and not PowerShell. I also couldn't reproduce the PowerShell sluggishness.

claunia commented

2026-01-31 02:28:43 +00:00

@JohnLukeBentley commented on GitHub (Jan 29, 2021):

@rebane2001 but, even if you aren't opening a Powershell tab in WT, you'll have Windows Powershell Legacy (e.g. 5.1) installed (given it is baked into Windows).

When I experienced the slugishness it was in any kind of Windows Terminal command line tab: Powershell Core; Powershell Legacy; and even Windows Command Prompt (cmd.exe), e.g. when typing and executing ipconfig. This is now removed for me.

If you install a Windows Powershell core 32 bit version (e.g. https://github.com/PowerShell/PowerShell/releases/download/v7.1.1/PowerShell-7.1.1-win-x86.msi) and execute Linux commands from Windows Terminal from whatever command line you like, e.g. Windows Command Prompt does that remove the sluggisness you've been experiencing?

(This is assuming I haven't misuderstood that with WSL installed and enabled when using Windows Terminal you don't get some Linux specifc command line. But in that case the question would remain: does having a Windows Powershell core 32 bit version installed neverthless remove the sluggishness you are experiencing?)

@JohnLukeBentley commented on GitHub (Jan 29, 2021): @rebane2001 but, even if you aren't opening a Powershell tab in WT, you'll have Windows Powershell Legacy (e.g. 5.1) *installed* (given it is baked into Windows). When I experienced the slugishness it was in any kind of Windows Terminal command line tab: Powershell Core; Powershell Legacy; and even Windows Command Prompt (cmd.exe), e.g. when typing and executing `ipconfig`. This is now removed for me. If you install a Windows Powershell core 32 bit version (e.g. https://github.com/PowerShell/PowerShell/releases/download/v7.1.1/PowerShell-7.1.1-win-x86.msi) and execute Linux commands from Windows Terminal from whatever command line you like, e.g. Windows Command Prompt does that remove the sluggisness you've been experiencing? (This is assuming I haven't misuderstood that with WSL installed and enabled when using Windows Terminal you don't get some Linux specifc command line. But in that case the question would remain: does having a Windows Powershell core 32 bit version installed neverthless remove the sluggishness you are experiencing?)

claunia commented

2026-01-31 02:28:43 +00:00

@JohnLukeBentley commented on GitHub (Feb 3, 2021):

After leaving my Windows Terminal open for more than 24 hours (after an uninstall of Powershell 64 bit and install of Powershell 32 bit) no sluggishness has reappeared. Nor is Tab switching (just two tabs) slow.

@JohnLukeBentley commented on GitHub (Feb 3, 2021): After leaving my Windows Terminal open for more than 24 hours (after an uninstall of Powershell 64 bit and install of Powershell 32 bit) no sluggishness has reappeared. Nor is Tab switching (just two tabs) slow.

claunia commented

2026-01-31 02:28:44 +00:00

@stedaniels commented on GitHub (Feb 3, 2021):

@Don-Vito do you still need a repro for this, or have you managed it yourself yet?

@stedaniels commented on GitHub (Feb 3, 2021): @Don-Vito do you still need a repro for this, or have you managed it yourself yet?

claunia commented

2026-01-31 02:28:44 +00:00

@Don-Vito commented on GitHub (Feb 3, 2021):

@Don-Vito do you still need a repro for this, or have you managed it yourself yet?

@stedaniels - no I didn't. A repro would be lovely 😊

@Don-Vito commented on GitHub (Feb 3, 2021): > @Don-Vito do you still need a repro for this, or have you managed it yourself yet? @stedaniels - no I didn't. A repro would be lovely :blush:

claunia commented

@JohnLukeBentley commented on GitHub (Feb 6, 2021):

Alas the update of Windows Terminal (automatically through the store) to 1.5.10271.0 has made the sluggishness return, with Powershell 32 bit installed.

@JohnLukeBentley commented on GitHub (Feb 6, 2021): Alas the update of Windows Terminal (automatically through the store) to 1.5.10271.0 has made the sluggishness return, with Powershell 32 bit installed.

claunia commented

@JohnLukeBentley commented on GitHub (Feb 6, 2021):

The sluggishness is worse in Windows Terminal (preview) 1.6.10272.0.

@JohnLukeBentley commented on GitHub (Feb 6, 2021): The sluggishness is worse in Windows Terminal (preview) 1.6.10272.0.

claunia commented

@NeilMacMullen commented on GitHub (Feb 6, 2021):

I can't prove it (yet) but I think the newer version may spontaneously shut down after outputting large amounts of text to a tab.

@NeilMacMullen commented on GitHub (Feb 6, 2021): I can't prove it (yet) but I think the newer version may spontaneously shut down after outputting large amounts of text to a tab.

claunia commented

@wrossmann commented on GitHub (Feb 12, 2021):

One thing I've noticed regarding this issue is that the length of time it takes to present itself as a problem seem to be related to how much output is happening in the tabs.

For example, my primary use is to have irssi running on the foreground tab, and then have a couple tabs for the odd command that I need to run. I'd say that irssi does a "medium" amount of output, the usual backgrounded tabs do virtually none, and I've left terminal running for weeks on end like this with no noticeable slowdown. However, recently I've been having some issues with my internet and I've been leaving mtr running in a background tab to keep a rough eye on packet loss. Within a day or two of running mtr with its "high" amount of output terminal starts to lag very noticeably and needs to be restarted.

I know that this is purely anecdotal, but it may be an avenue of investigation. It could be the general volume, background volume, or maybe something that ncurses does that tickles terminal in the wrong way.

Thanks for coming to my TED Talk.

@wrossmann commented on GitHub (Feb 12, 2021): One thing I've noticed regarding this issue is that the length of time it takes to present itself as a problem seem to be related to how much output is happening in the tabs. For example, my primary use is to have irssi running on the foreground tab, and then have a couple tabs for the odd command that I need to run. I'd say that irssi does a "medium" amount of output, the usual backgrounded tabs do virtually none, and I've left terminal running for weeks on end like this with no noticeable slowdown. However, recently I've been having some issues with my internet and I've been leaving mtr running in a background tab to keep a rough eye on packet loss. Within a day or two of running mtr with its "high" amount of output terminal starts to lag very noticeably and needs to be restarted. I know that this is purely anecdotal, but it may be an avenue of investigation. It could be the general volume, background volume, or maybe something that ncurses does that tickles terminal in the wrong way. Thanks for coming to my TED Talk.

claunia commented

@rebane2001 commented on GitHub (Feb 15, 2021):

I can confirm what @NeilMacMullen is saying - I've had the Terminal crash after running for a while. Often when the Terminal is on the brim of crashing, resizing the window forces a crash.

@rebane2001 commented on GitHub (Feb 15, 2021): I can confirm what @NeilMacMullen is saying - I've had the Terminal crash after running for a while. Often when the Terminal is on the brim of crashing, resizing the window forces a crash.

claunia commented

@NeilMacMullen commented on GitHub (Feb 15, 2021):

@rebane2001 That is interesting. I was beginning to think the "crash" was actually due to WIndows Store performing a background update (which forces any open terminals to close - see https://github.com/microsoft/terminal/issues/3915).

@NeilMacMullen commented on GitHub (Feb 15, 2021): @rebane2001 That is interesting. I was beginning to think the "crash" was actually due to WIndows Store performing a background update (which forces any open terminals to close - see https://github.com/microsoft/terminal/issues/3915).

claunia commented

@rebane2001 commented on GitHub (Feb 15, 2021):

I am fairly certain that my crashes have not been caused by updates

@rebane2001 commented on GitHub (Feb 15, 2021): I am fairly certain that my crashes have not been caused by updates

claunia commented

@JohnLukeBentley commented on GitHub (Mar 1, 2021):

My sluggishness has disappeared with WT preview version: 1.6.10412.0 (autoupdated through Windows Store).

A point relevant to #3515 (as I've previously mentioned I can't tell if these two issues are two faces of the same cause).

@JohnLukeBentley commented on GitHub (Mar 1, 2021): My sluggishness has disappeared with WT preview version: 1.6.10412.0 (autoupdated through Windows Store). A point relevant to #3515 (as I've previously mentioned I can't tell if these two issues are two faces of the same cause).

claunia commented

@desmap commented on GitHub (Mar 2, 2021):

On 1.6.10412.0 and I was about to post a similar video as in https://github.com/microsoft/terminal/issues/7710#issuecomment-719803095 from @rebane2001.

I am using Windows Terminal as my daily driver for some weeks now. Today, I had to finish some procrastinated work and somehow, I intuitively just closed Terminal and started WSL2. What can I say, it felt like back home and I was finally working. I didn't know about this issue/thread here before.

FWIW, then I restarted Windows Terminal to check if this lag is still there. And it is, so it even doesn't has to run for long. It's subtle but enough to annoy you. The bigger the window the more it's obvious. If I add transparency via AHK even more but not at all with WSL2 with AHK-added transparency. Even if you put both Terminal and WSL2 above each other, turn on AHK transparency on both and do quick cursor movements in vim, you see the lag better, even if you do (send) the movements in Terminal (you need tmux for this, btw).

FWIW2, I work on a remote server via ssh and with tmux.

Edit: I am now back to WSL2 for around 2-3 hours and, this is now highly subjective but yeah, my notebook fans are almost silent, before on Terminal there weren't. Not that Terminal created a huge workload so the fans went to max, no, it was just slightly more and enough to be felt. I ran next to Terminal/WSL2 just one Chrome window with few tabs and Spotify.

@desmap commented on GitHub (Mar 2, 2021): On 1.6.10412.0 and I was about to post a similar video as in https://github.com/microsoft/terminal/issues/7710#issuecomment-719803095 from @rebane2001. I am using Windows Terminal as my daily driver for some weeks now. Today, I had to finish some procrastinated work and somehow, I intuitively just closed Terminal and started WSL2. What can I say, it felt like back home and I was finally working. I didn't know about this issue/thread here before. FWIW, then I restarted Windows Terminal to check if this lag is still there. And it is, so it even doesn't has to run for long. It's subtle but enough to annoy you. The bigger the window the more it's obvious. If I add transparency via AHK even more but not at all with WSL2 with AHK-added transparency. Even if you put both Terminal and WSL2 above each other, turn on AHK transparency on both and do quick cursor movements in vim, you see the lag better, even if you do (send) the movements in Terminal (you need tmux for this, btw). FWIW2, I work on a remote server via ssh and with tmux. Edit: I am now back to WSL2 for around 2-3 hours and, this is now highly subjective but yeah, my notebook fans are almost silent, before on Terminal there weren't. Not that Terminal created a huge workload so the fans went to max, no, it was just slightly more and enough to be felt. I ran next to Terminal/WSL2 just one Chrome window with few tabs and Spotify.

claunia commented

@Cuberick-Orion commented on GitHub (Mar 10, 2021):

Similar issue here. My usual scenario is: multiple tabs on wsl2, each with an ssh connected to a remote server, with (usually) many outputs.

In addition to the Terminal being sluggish, I also notice a constantly increasing memory usage by its main process. For 4-5 days the usage could grow to 2GB in total.

Would appreciate any comments.

@Cuberick-Orion commented on GitHub (Mar 10, 2021): Similar issue here. My usual scenario is: multiple tabs on `wsl2`, each with an `ssh` connected to a remote server, with (usually) many outputs. In addition to the Terminal being sluggish, I also notice a constantly increasing memory usage by its main process. For 4-5 days the usage could grow to 2GB in total. Would appreciate any comments.

claunia commented

@mengx8 commented on GitHub (Mar 10, 2021):

I have same problem 1.6.10571.0

@mengx8 commented on GitHub (Mar 10, 2021): I have same problem 1.6.10571.0

claunia commented

@bartoszek commented on GitHub (Mar 16, 2021):

I'm using tmux session inside WSL:Ubuntu image and after detaching session [ctrl-a]d, restarting Terminal:16.10571.0 and reconnecting with tmux a speed is back at normal and memory usage is back at reasonable ~30MB
This issue is really pain full, after few days typing speed goes down to like 2char/sec on my thinkpad w530 😢 ( how is that cygwin is able to deliver with all it's overhang and native application isn't :feelsgood: )

@bartoszek commented on GitHub (Mar 16, 2021): I'm using `tmux` session inside `WSL:Ubuntu` image and after detaching session `[ctrl-a]d`, restarting `Terminal:16.10571.0` and reconnecting with `tmux a` speed is back at normal and memory usage is back at reasonable `~30MB` This issue is really pain full, after few days typing speed goes down to like 2char/sec on my thinkpad w530 😢 ( how is that `cygwin` is able to deliver with all it's overhang and native application isn't :feelsgood: )

claunia commented

@zadjii-msft commented on GitHub (Mar 16, 2021):

You know, if we knew what was causing this one, we would have solved it by now. Unfortunately, we still don't have a good repro, and we don't have any traces of a terminal in this state, so there's not much to work with 😕

@zadjii-msft commented on GitHub (Mar 16, 2021): You know, if we knew what was causing this one, we would have solved it by now. Unfortunately, we still don't have a good repro, and we don't have any traces of a terminal in this state, so there's not much to work with 😕

claunia commented

@alexandermalfait commented on GitHub (Mar 16, 2021):

@zadjii-msft , I did send you a dump on october 26th

Did that not help to find a root cause for this issue? Seems to me like it's memory leak.

@alexandermalfait commented on GitHub (Mar 16, 2021): @zadjii-msft , I did [send you a dump](https://github.com/microsoft/terminal/issues/7710#issuecomment-716423695) on october 26th Did that not help to find a root cause for this issue? Seems to me like it's memory leak.

claunia commented

@zadjii-msft commented on GitHub (Mar 16, 2021):

holy crap there's a dump

Sorry I was on paternity leave at the time so I was not regularly checking mail. That's what I get for checking mail on "vacation" 😆

Would you mind sending it again? I think the link expired?

@zadjii-msft commented on GitHub (Mar 16, 2021): holy crap there's a dump Sorry I was on paternity leave at the time so I was not regularly checking mail. That's what I get for checking mail on "vacation" 😆 Would you mind sending it again? I think the link expired?

claunia commented

@alexandermalfait commented on GitHub (Mar 16, 2021):

No problem! We can all agree babies are vastly more interesting than memory leaks :)

Indeed the link has expired, and I'm searching high and low but can't the original file anywhere.
I restarted my terminal this morning, I'll wait a few days for the issue to pop back up and send you a new dump.

@alexandermalfait commented on GitHub (Mar 16, 2021): No problem! We can all agree babies are vastly more interesting than memory leaks :) Indeed the link has expired, and I'm searching high and low but can't the original file anywhere. I restarted my terminal this morning, I'll wait a few days for the issue to pop back up and send you a new dump.

claunia commented

@alexandermalfait commented on GitHub (Mar 16, 2021):

PS: is there a way I can send you the link privately?
I guess the dump will contain terminal output, which will probably have sensitive data in it.

@alexandermalfait commented on GitHub (Mar 16, 2021): PS: is there a way I can send you the link privately? I guess the dump will contain terminal output, which will probably have sensitive data in it.

claunia commented

@zadjii-msft commented on GitHub (Mar 16, 2021):

Sure thing, my email is in my profile ☺️

@zadjii-msft commented on GitHub (Mar 16, 2021): Sure thing, my email is in my profile ☺️

claunia commented

@desmap commented on GitHub (Mar 19, 2021):

Tried Terminal again after a while, wanted to do some comparison/screen recording, all was good and before moving on I went to the kitchen to get me some coffee.

When I came back, my notebook fans were to the max, so opened my task manager and saw this on the "3D" chart:

So, I slowly closed first Chrome, then Spotify and eventually, Terminal, take a look:

@desmap commented on GitHub (Mar 19, 2021): Tried Terminal again after a while, wanted to do some comparison/screen recording, all was good and before moving on I went to the kitchen to get me some coffee. When I came back, my notebook fans were to the max, so opened my task manager and saw this on the "3D" chart: ![image](https://user-images.githubusercontent.com/43666255/111770950-5910f200-88ab-11eb-8556-9b5b88e559c1.png) So, I slowly closed first Chrome, then Spotify and eventually, Terminal, take a look: ![image](https://user-images.githubusercontent.com/43666255/111771338-d5a3d080-88ab-11eb-8e30-4722598c3f44.png)

claunia commented

@alexandermalfait commented on GitHub (Mar 19, 2021):

@zadjii-msft , I've sent you a new dump over WeTransfer, dit you receive it?

Primary "symptom" I'm seeing is slow tab switching, like a second of delay. After restarting Terminal, tab switching is instant again.

@alexandermalfait commented on GitHub (Mar 19, 2021): @zadjii-msft , I've sent you a new dump over WeTransfer, dit you receive it? Primary "symptom" I'm seeing is slow tab switching, like a second of delay. After restarting Terminal, tab switching is instant again.

claunia commented

@deepend-tildeclub commented on GitHub (Mar 20, 2021):

Sounds like my issue.. Most times I only have one tab open with a SSH session to my server and windows terminal will be using 1.6GB of ram and very slow to respond to clicks and eventually slow to even type in the terminal.
My pc is not slow its 8cores 16threads with 32GB ram, NVME SSD.. So don't understand why it would get sluggish.

@deepend-tildeclub commented on GitHub (Mar 20, 2021): Sounds like my issue.. Most times I only have one tab open with a SSH session to my server and windows terminal will be using 1.6GB of ram and very slow to respond to clicks and eventually slow to even type in the terminal. My pc is not slow its 8cores 16threads with 32GB ram, NVME SSD.. So don't understand why it would get sluggish.

claunia commented

@DS992 commented on GitHub (Mar 25, 2021):

Experiencing the same issue using WT Preview V 1.7.572.0. I am also a heavy user of tmux (through WSL2).

Clearing the history does nothing. Killing tmux does nothing. It gets slower over time and/or due to the amount of text output in the terminal. For me at least.

Opening a new window (not tab) of WT Preview seems to make it work normally, but the other Windows (which I kept open) is still "sluggish".

So this is not a critical issue, but it's extremely annoying.

@DS992 commented on GitHub (Mar 25, 2021): Experiencing the same issue using WT Preview V 1.7.572.0. I am also a heavy user of tmux (through WSL2). Clearing the history does nothing. Killing tmux does nothing. It gets slower over time and/or due to the amount of text output in the terminal. For me at least. Opening a new window (not tab) of WT Preview seems to make it work normally, but the other Windows (which I kept open) is still "sluggish". So this is not a critical issue, but it's extremely annoying.

claunia commented

@BryceEakin commented on GitHub (Apr 3, 2021):

Reported the same issue separately - my mistake. Here's my summary and diagnostic data. Hope it helps get this resolved. Definitely an annoyance, though Windows Terminal has been a huge win in my workflow.

Windows Feedback link for diagnostic data: https://aka.ms/AAbj0dj

@BryceEakin commented on GitHub (Apr 3, 2021): Reported the same issue separately - my mistake. Here's my summary and diagnostic data. Hope it helps get this resolved. Definitely an annoyance, though Windows Terminal has been a huge win in my workflow. Windows Feedback link for diagnostic data: https://aka.ms/AAbj0dj

claunia commented

@miniksa commented on GitHub (Apr 6, 2021):

I think I have an idea on this. I need to capture allocation traces for DispatcherTimers as I have a 2GB dump from this state that shows almost 2 million of those allocated and alive in the heap.

@miniksa commented on GitHub (Apr 6, 2021): I think I have an idea on this. I need to capture allocation traces for `DispatcherTimer`s as I have a 2GB dump from this state that shows almost 2 million of those allocated and alive in the heap.

claunia commented

@miniksa commented on GitHub (Apr 6, 2021):

ThrottledFunc<> leaks DispatcherTimer instances in two spots:

TerminalControl!<lambda_8050e662c890fd8b88061e60f2bb6336>::operator()+0x6d [E:\BA\3\s\src\cascadia\TerminalControl\ThrottledFunc.h @ 62]

and
TerminalControl!<lambda_922c48371e5965b2d4b2a51a49c8c9c3>::operator()+0x6d [E:\BA\3\s\src\cascadia\TerminalControl\ThrottledFunc.cpp @ 41]

Something about the pattern they're using is making an extra ref/instance that never gets let go and just consumes more and more over time...

@miniksa commented on GitHub (Apr 6, 2021): `ThrottledFunc<>` leaks `DispatcherTimer` instances in two spots: TerminalControl!<lambda_8050e662c890fd8b88061e60f2bb6336>::operator()+0x6d [E:\BA\3\s\src\cascadia\TerminalControl\ThrottledFunc.h @ 62] and TerminalControl!<lambda_922c48371e5965b2d4b2a51a49c8c9c3>::operator()+0x6d [E:\BA\3\s\src\cascadia\TerminalControl\ThrottledFunc.cpp @ 41] Something about the pattern they're using is making an extra ref/instance that never gets let go and just consumes more and more over time...

claunia commented

@YAMLcase commented on GitHub (Apr 8, 2021):

This sounds very promising! I'm getting about 6 hours of work before I have to wsl --shutdown so would be able to tell almost immediately if there's improvement. Would it be possible to provide a hotfix build?

@YAMLcase commented on GitHub (Apr 8, 2021): This sounds very promising! I'm getting about 6 hours of work before I have to `wsl --shutdown` so would be able to tell almost immediately if there's improvement. Would it be possible to provide a hotfix build?

claunia commented

@zadjii-msft commented on GitHub (Apr 8, 2021):

Well, the next release is already scheduled for sometime next week, so probably not? We'd want to selfhost it internally too and make sure we didn't accidentally make this worse 😅

@zadjii-msft commented on GitHub (Apr 8, 2021): Well, the next release is already scheduled for sometime next week, so probably not? We'd want to selfhost it internally too and make sure we didn't accidentally make this worse 😅

claunia commented

@panicfarm commented on GitHub (Apr 9, 2021):

This bug is very serious. I Many programmers need the terminal running for a long time in order not to lose state, but it becomes unusable after several days.

@panicfarm commented on GitHub (Apr 9, 2021): This bug is very serious. I Many programmers need the terminal running for a long time in order not to lose state, but it becomes unusable after several days.

claunia commented

@zadjii-msft commented on GitHub (Apr 9, 2021):

@panicfarm then you'll be happy to know that the root cause was found and should be fixed in the next preview build ☺️

@zadjii-msft commented on GitHub (Apr 9, 2021): @panicfarm then you'll be happy to know that the root cause was found and should be fixed in the next preview build ☺️

claunia commented

@ghost commented on GitHub (Apr 14, 2021):

:tada:This issue was addressed in #9729, which has now been successfully released as Windows Terminal v1.7.1033.0.🎉

Handy links:

@ghost commented on GitHub (Apr 14, 2021): :tada:This issue was addressed in #9729, which has now been successfully released as `Windows Terminal v1.7.1033.0`.:tada: Handy links: * [Release Notes](https://github.com/microsoft/terminal/releases/tag/v1.7.1033.0) * [Store Download](https://www.microsoft.com/store/apps/9n8g5rfz9xk3?cid=storebadge&ocid=badge)

claunia commented