starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-09-25 00:15:10 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Windows Terminal laptop user experience and resources usage #22854

New Issue
Closed
opened 2026-01-31 08:25:18 +00:00 by claunia · 7 comments
claunia commented 2026-01-31 08:25:18 +00:00
Owner
Copy Link

Originally created by @ChGen on GitHub (Feb 6, 2025).

Windows Terminal version

1.21.10351.0

Windows build number

10.0.26100.2894

Other Software

MS Windows 11 24H2
Intel GPU driver 32.0.*
NVIDIA GPU driver 32.0.*

MS WT 1.21.10351.0
MS WT Preview 1.23.10353.0
WT Renderer: Direct3D11
Transparency/acrylic effects disabled
CkearType smoothing enabled

Steps to reproduce

While using my office laptop I noticed some shortage of memory and some noise/high system load. And battery life wasn't good too.
When investigating, I found out that MS Windows Terminal uses 1.5 to 2.5GB of RAM and quite high of CPU and GPU.
I gradually updated Windows 11 to 24H2 and Intel GPU driver from 30.0.* to 32.0.* version, but it didn't help.

  1. Office laptop. i7-1260p, 16B RAM, Intel Iris XE GPU, 3000x2000@90Hz display.
  • MS WT uses up to 2.5GB of RAM (including shared VRAM) and high CPU/GPU. 7 to 15 tabs.
  • 90Hz vs 60Hz refresh rate further increases CPU & GPU load, noticeably, for all active & inactive tabs if they do regular output.
  • RAM usage is similar or higher than Firefox browser with several tabs and MS VSCode IDE with plugins and project (which uses GPU & has terminals too).
  • CPU, GPU and RAM usage is much higher than in PowerShell ISE IDE terminals (build-in Windows app, .NET+WPF, hardware accelerated rendering, 0.3 vs 2GB). PS IDE supports multiple PowerShell terminal tabs.
  • CPU, GPU and RAM usage is much higher than in ConEmu-like terminal apps with tabs, which isn't "GPU acceleated" (0.2GB vs 2GB). And ConEmu doesn't use CPU & GPU for inactive tabs.
  • 2GB RAM is huge amount for mostly text based rendering app. Also, there are a lot of laptops with 8 to 24GB RAM with high DPI / high refresh rate screen, including MS Surface laptops line.

So I've made fresh measurements on my personal hardware and clearly reproduced high resource usage:

  1. PC. i7-14700K + NVIDIA RTX 4070tiS + 4k@120Hz Display
    WT Stable, memory:
    0.5GB RAM + 1.0GB VRAM (10 powershell tabs)
    workload, active/inactive tab: CPU 9%/9%; GPU 6-7% / 5-6%
    WT Preview:
    0.4GB RAM +1.0GB VRAM (10T)
    workload: CPU 9%/9%; GPU 6-7% / 5-6%
    PowerShell ISE, memory:
    0.2B RAM + 0.2GB VRAM (10 tabs)
    workload: CPU 9/9%; GPU 15 to 1%
    PowerShell Window (or ConEmu-like tabbed terminal)
    workload: CPU 9/8%; GPU 10-30% to 0%
  2. Laptop. Intel i7-1260p, 32GB RAM, Iris XE GPU, 2560x1600@60Hz
    MS WT, memory
    1.1GB RAM (including 0.4GB shared VRAM) 10 PS Tabs
    workload: CPU 18/18%; CPU 17/17%
    WT Preview, memory
    1.0GB RAM (0.7GB VRAM) 10T
    workload: CPU 19/19%; CPU 19/18%
    PS ISE, memory
    0.3GB RAM (0.2GB VRAM) 10T
    workload: 19/18%; GPU 19/1%
    PS Window (basic, not "gpu accelerated"):
    workload: CPU: 18/18%; GPU 45/0%

workload: single tab workload, powershell tab, ls -R \. Measuring load on active and inactive tab (minimized window).

Expected Behavior

  • Inactive tabs don't strain CPU and GPU
  • Minimized and invisible windows don't strain CPU and GPU
  • RAM and VRAM usage comparable at least to .NET WPF apps like PowerShell ISE IDE, and not like full blown IDE and web browser. Ideally, close to ConEmu like terminal apps.
  • Single rendering context per app/window with restricted (eviction) and configurable vram cache size?
  • Windows Terminal stays energy and memory efficient with multiple tabs. Laptop stays silent.

Actual Behavior

  • inactive tabs strain CPU and GPU (laptops battery & fan noise!)
  • Minimized and invisible windows do strain CPU and GPU.
  • inactive tabs strain CPU and GPU on current display refresh rate frequency (some laptops could be up to 3840x2400 or 240hz btw.)
  • RAM and VRAM usage comparable or higher than in IDE or browser.
  • laptop gets reduced battery life and increased noise
Originally created by @ChGen on GitHub (Feb 6, 2025). ### Windows Terminal version 1.21.10351.0 ### Windows build number 10.0.26100.2894 ### Other Software MS Windows 11 24H2 Intel GPU driver 32.0.* NVIDIA GPU driver 32.0.* MS WT 1.21.10351.0 MS WT Preview 1.23.10353.0 WT Renderer: Direct3D11 Transparency/acrylic effects disabled CkearType smoothing enabled ### Steps to reproduce While using my office laptop I noticed some shortage of memory and some noise/high system load. And battery life wasn't good too. When investigating, I found out that MS Windows Terminal uses 1.5 to 2.5GB of RAM and quite high of CPU and GPU. I gradually updated Windows 11 to 24H2 and Intel GPU driver from 30.0.* to 32.0.* version, but it didn't help. 0. Office laptop. i7-1260p, 16B RAM, Intel Iris XE GPU, 3000x2000@90Hz display. * MS WT uses up to 2.5GB of RAM (including shared VRAM) and high CPU/GPU. 7 to 15 tabs. * 90Hz vs 60Hz refresh rate further increases CPU & GPU load, noticeably, for all active & inactive tabs if they do regular output. * RAM usage is similar or higher than Firefox browser with several tabs and MS VSCode IDE with plugins and project (which uses GPU & has terminals too). * CPU, GPU and RAM usage is much higher than in PowerShell ISE IDE terminals (build-in Windows app, .NET+WPF, hardware accelerated rendering, 0.3 vs 2GB). PS IDE supports multiple PowerShell terminal tabs. * CPU, GPU and RAM usage is much higher than in `ConEmu`-like terminal apps with tabs, which isn't "GPU acceleated" (0.2GB vs 2GB). And ConEmu doesn't use CPU & GPU for inactive tabs. * 2GB RAM is huge amount for mostly text based rendering app. Also, there are a lot of laptops with 8 to 24GB RAM with high DPI / high refresh rate screen, including MS Surface laptops line. So I've made fresh measurements on my personal hardware and clearly reproduced high resource usage: 1. PC. i7-14700K + NVIDIA RTX 4070tiS + 4k@120Hz Display **WT Stable, memory:** 0.5GB RAM + 1.0GB VRAM (10 powershell tabs) workload, active/inactive tab: CPU 9%/9%; GPU 6-7% / 5-6% **WT Preview:** 0.4GB RAM +1.0GB VRAM (10T) workload: CPU 9%/9%; GPU 6-7% / 5-6% **PowerShell ISE, memory:** 0.2B RAM + 0.2GB VRAM (10 tabs) workload: CPU 9/9%; GPU 15 to 1% **PowerShell Window** (or ConEmu-like tabbed terminal) workload: CPU 9/8%; GPU 10-30% to 0% 2. Laptop. Intel i7-1260p, 32GB RAM, Iris XE GPU, 2560x1600@60Hz **MS WT, memory** 1.1GB RAM (including 0.4GB shared VRAM) 10 PS Tabs workload: CPU 18/18%; CPU 17/17% **WT Preview, memory** 1.0GB RAM (0.7GB VRAM) 10T workload: CPU 19/19%; CPU 19/18% **PS ISE, memory** 0.3GB RAM (0.2GB VRAM) 10T workload: 19/18%; GPU 19/1% **PS Window** (basic, not "gpu accelerated"): workload: CPU: 18/18%; GPU 45/0% **workload: single tab workload, powershell tab, `ls -R \`. Measuring load on active and inactive tab (minimized window).** ### Expected Behavior * Inactive tabs don't strain CPU and GPU * Minimized and invisible windows don't strain CPU and GPU * RAM and VRAM usage comparable at least to .NET WPF apps like PowerShell ISE IDE, and not like full blown IDE and web browser. Ideally, close to `ConEmu` like terminal apps. * Single rendering context per app/window with restricted (eviction) and configurable vram cache size? * Windows Terminal stays energy and memory efficient with multiple tabs. Laptop stays silent. ### Actual Behavior * inactive tabs strain CPU and GPU (laptops battery & fan noise!) * Minimized and invisible windows do strain CPU and GPU. * inactive tabs strain CPU and GPU on current display refresh rate frequency (some laptops could be up to 3840x2400 or 240hz btw.) * RAM and VRAM usage comparable or higher than in IDE or browser. * laptop gets reduced battery life and increased noise
claunia added the Needs-TriageIssue-BugResolution-Duplicate labels 2026-01-31 08:25:18 +00:00
claunia commented 2026-01-31 08:25:19 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Feb 10, 2025):

"0.5GB RAM" roughly matches what one would see if they used Task Manager to observe the memory usage of our application. But that includes the memory used by any shell we spawn, and any other child process of the shell spawns. Those don't belong to us.

I have similar hardware to your PC, and you should see roughly 100MB CPU-side. The GPU-side memory usage depends on the window size, because it's caused by us having to allocate a swap chain (GPU texture for display output) for each tab. Its usage depends on your display resolution and window size. For me that's 300MB for 10 tabs in a 120x30 cell window. Each tab gets one OpenConsole.exe process which belongs to Windows Terminal and consumes an additional ~1.7MB. Any other process listed in Task Manager does not belong to us.

The excessive memory usage is caused by two things:

  • Us creating one D3D11 device per tab (or pane). We should only create one and share it between all tabs. This requires some large refactors to allow for sharing swap chains and devices between tabs. This is tracked here: #15186. Reduction of memory usage depends on how much memory the device driver allocates. In case of Nvidia that's roughly 7MB of memory on the CPU-side (per tab/pane). More importantly, the reduction in GPU-memory is proportional to the window size and so we could reduce
  • By using the so-called ConPTY as a child process instead of using it in-process. Fixing this is tracked by several issues, but perhaps #15976 is a good one. That would get rid of the additional ~1.7MB.

If you'd like to investigate this further, I'd recommend using something like this if you aren't already (I personally use the former):

You can modify their main view and add columns to show the "WS Private" and GPU memory usage. I think it'd be best if you sent us screenshots of what you're seeing, because that ensures that there aren't any misunderstandings.

@lhecker commented on GitHub (Feb 10, 2025): "0.5GB RAM" roughly matches what one would see if they used Task Manager to observe the memory usage of our application. But that includes the memory used by any shell we spawn, and any other child process of the shell spawns. Those don't belong to us. I have similar hardware to your PC, and you should see roughly 100MB CPU-side. The GPU-side memory usage depends on the window size, because it's caused by us having to allocate a swap chain (GPU texture for display output) for each tab. Its usage depends on your display resolution and window size. For me that's 300MB for 10 tabs in a 120x30 cell window. Each tab gets one OpenConsole.exe process which belongs to Windows Terminal and consumes an additional ~1.7MB. Any other process listed in Task Manager does not belong to us. The excessive memory usage is caused by two things: * Us creating one D3D11 device per tab (or pane). We should only create one and share it between all tabs. This requires some large refactors to allow for sharing swap chains and devices between tabs. This is tracked here: #15186. Reduction of memory usage depends on how much memory the device driver allocates. In case of Nvidia that's roughly 7MB of memory on the CPU-side (per tab/pane). More importantly, the reduction in GPU-memory is proportional to the window size and so we could reduce * By using the so-called ConPTY as a child process instead of using it in-process. Fixing this is tracked by several issues, but perhaps #15976 is a good one. That would get rid of the additional ~1.7MB. If you'd like to investigate this further, I'd recommend using something like this if you aren't already (I personally use the former): * https://systeminformer.com/ * https://learn.microsoft.com/en-us/sysinternals/downloads/process-explorer You can modify their main view and add columns to show the "WS Private" and GPU memory usage. I think it'd be best if you sent us screenshots of what you're seeing, because that ensures that there aren't any misunderstandings.
claunia commented 2026-01-31 08:25:19 +00:00
Author
Owner
Copy Link

@ChGen commented on GitHub (Feb 11, 2025):

@lhecker , thanks for your respose, I'll try it and provide screenshots. Currently I measured memory usage by Windows Terminal, PowerShell ISE IDE and other apps as follows:

  • Closing all third-party apps, including browser and apps in tray.
  • Opening minimised PowerShell Window to keep shared PowerShell part always in memory, so it won't add up; Also, opening Task Manager.
  • Opening target app with maximised window (and default font size) and creating 10 powershell tabs. For 13 - 15" laptops maximised terminal window feels natural and most convenient user-wise.
  • Writing down memory usage values for RAM and VRAM on Performance tab of Task Manager. Since apps could be multi-process and ram could be sharable, and VRAM could be sharable with dwm.exe, at least, I use total usage values.
  • Closing target app
  • Writing down memory usage values for RAM and VRAM on Performance tab of Task Manager.
  • Difference between two measurements is my RAM and VRAM usage values. I found it quite stable and reproducible.
  • Since most of the modern laptops have quite high resolution screen, soldered RAM and integrated GPU with VRAM dynamically allocated from the RAM, total usage values are very relevant.
@ChGen commented on GitHub (Feb 11, 2025): @lhecker , thanks for your respose, I'll try it and provide screenshots. Currently I measured memory usage by `Windows Terminal`, `PowerShell ISE IDE` and other apps as follows: * Closing all third-party apps, including browser and apps in tray. * Opening minimised PowerShell Window to keep shared PowerShell part always in memory, so it won't add up; Also, opening Task Manager. * Opening target app with maximised window (and default font size) and creating 10 powershell tabs. For 13 - 15" laptops maximised terminal window feels natural and most convenient user-wise. * Writing down memory usage values for RAM and VRAM on Performance tab of Task Manager. Since apps could be multi-process and ram could be sharable, and VRAM could be sharable with `dwm.exe`, at least, I use total usage values. * Closing target app * Writing down memory usage values for RAM and VRAM on Performance tab of Task Manager. * Difference between two measurements is my RAM and VRAM usage values. I found it quite stable and reproducible. * Since most of the modern laptops have quite high resolution screen, soldered RAM and integrated GPU with VRAM dynamically allocated from the RAM, total usage values are very relevant.
claunia commented 2026-01-31 08:25:20 +00:00
Author
Owner
Copy Link

@ChGen commented on GitHub (Feb 11, 2025):

Below is Process Explorer view with GPU memory column for 10 PowerShell tabs in Windows Terminal Preview. 2560x1600 screen, Intel Iris XE graphics.

Image

@ChGen commented on GitHub (Feb 11, 2025): Below is Process Explorer view with GPU memory column for 10 PowerShell tabs in Windows Terminal Preview. 2560x1600 screen, Intel Iris XE graphics. ![Image](https://github.com/user-attachments/assets/12fa2c25-4a5e-4bab-8196-120e8fc9e31f)
claunia commented 2026-01-31 08:25:20 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Feb 26, 2025):

The CPU memory usage is a little misleading.

  • "Private Bytes" is the total amount of memory that a process owns just for itself (not shared with anyone). It includes both physical memory and memory backed by the page file. In other words, virtual memory that may not be backed by anything yet. It's the maximum possible amount of memory it could use if it wanted to, but it doesn't have to.
  • "Working Set" is the total amount of memory that is actually being used. But this includes memory that is shared with other processes, and memory that can be freed immediately if there's memory pressure.

What's most interesting is the intersection between the two: Memory it owns exclusively (private) and is actually being used. That's the so called "WS Private Bytes" (WS = Working Set of course). You can show that value when you right click the table header. There should be an option to choose the columns and in the memory tab you can add this column. It should be around 100MB.

Regarding the GPU System Memory, that's indeed quite a bit much, but I know our rendering code quite well
(I wrote it) and I don't believe we're doing anything wrong. What we should do is #15186 but architecturally that's really difficult to do in this large project (its current architecture is "not ideal").

If you do napkin math: Your display is 2560x1600 pixel and each pixel is 4 byte. There are 3 render targets for the swap chain (triple buffering), which means each swap chain is 256016004*3 = 49MB large. 10 tabs result in at least 490MB of memory usage. There's another 49MB for the swap chain that the UI framework uses. And GPU memory has a minimum alignment of ~64KiB, so there's probably some overhead. This could explain why 733MB are used. As mentioned above, #15186 is meant to address this blowup.

@lhecker commented on GitHub (Feb 26, 2025): The CPU memory usage is a little misleading. * "Private Bytes" is the total amount of memory that a process owns just for itself (not shared with anyone). It includes both physical memory and memory backed by the page file. In other words, virtual memory that may not be backed by anything yet. It's the maximum possible amount of memory it could use if it wanted to, but it doesn't have to. * "Working Set" is the total amount of memory that is actually being used. But this includes memory that is shared with other processes, and memory that can be freed immediately if there's memory pressure. What's most interesting is the intersection between the two: Memory it owns exclusively (private) and is actually being used. That's the so called "WS Private Bytes" (WS = Working Set of course). You can show that value when you right click the table header. There should be an option to choose the columns and in the memory tab you can add this column. It should be around 100MB. Regarding the GPU System Memory, that's indeed quite a bit much, but I know our rendering code quite well (I wrote it) and I don't believe we're doing anything wrong. What we should do is #15186 but architecturally that's really difficult to do in this large project (its current architecture is "not ideal"). If you do napkin math: Your display is 2560x1600 pixel and each pixel is 4 byte. There are 3 render targets for the swap chain (triple buffering), which means each swap chain is 2560*1600*4*3 = 49MB large. 10 tabs result in at least 490MB of memory usage. There's another 49MB for the swap chain that the UI framework uses. And GPU memory has a minimum alignment of ~64KiB, so there's probably some overhead. This could explain why 733MB are used. As mentioned above, #15186 is meant to address this blowup.
claunia commented 2026-01-31 08:25:20 +00:00
Author
Owner
Copy Link

@ChGen commented on GitHub (Feb 27, 2025):

Thank you for your explanations. Yes, "WS Private Bytes" is smaller, about 165MB for me. Hope you'll find a way to switch to single rendering content (like PS ISE IDE does), since for most laptops RAM is dynamically shared with GPU and often soldered, not upgradable.

@ChGen commented on GitHub (Feb 27, 2025): Thank you for your explanations. Yes, "WS Private Bytes" is smaller, about 165MB for me. Hope you'll find a way to switch to single rendering content (like PS ISE IDE does), since for most laptops RAM is dynamically shared with GPU and often soldered, not upgradable.
claunia commented 2026-01-31 08:25:21 +00:00
Author
Owner
Copy Link

@ChGen commented on GitHub (Feb 27, 2025):

Another relevant issue on laptops is background tabs may use a lot of CPU & GPU time due to full rendering of invisible tabs. Especially on high resolution high refresh rate screens. Hope it could be improved too.

@ChGen commented on GitHub (Feb 27, 2025): Another relevant issue on laptops is background tabs may use a lot of CPU & GPU time due to full rendering of invisible tabs. Especially on high resolution high refresh rate screens. Hope it could be improved too.
claunia commented 2026-01-31 08:25:21 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Apr 9, 2025):

Thanks for the lively discussion here!

I'm going to close this as a duplicate of:

@DHowett commented on GitHub (Apr 9, 2025): Thanks for the lively discussion here! I'm going to close this as a duplicate of: - #15186 - #1989 - #5318
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Issue-Bug Needs-Triage Resolution-Duplicate
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#22854
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?