starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

cmd execution and GCC compilation scripts slow #554

New Issue
Closed
opened 2026-01-30 21:55:07 +00:00 by claunia · 9 comments
claunia commented 2026-01-30 21:55:07 +00:00
Owner
Copy Link

Originally created by @kjarvel on GitHub (Feb 6, 2019).

Configuration

Windows build number:

  • Windows 7 SP1: Microsoft Windows [Version 6.1.7601]
  • Windows 10 1809: Microsoft Windows [Version 10.0.17763.253]

What you're doing and what's happening:

With Windows 7, executing build_gcc.bat (1000 x gcc-arm-none-eabi) in Command Prompt takes 0:46.
With Windows 10, the same script takes +78% longer time with default settings (01:22).

With Windows 7, executing build_cmd.bat (1000 x cmd.exe x 20) in Command Prompt takes 01:48.
With Windows 10, the same script takes +139% longer time with default settings (04:18).

Some observations:
With Windows 10, some computers show heavy (25-40%) GPU load when Command Prompt is scrolling.
A Windows 7 Virtual Machine running build_cmd.bat in Virtual Box on a Windows 10 host outperforms the Windows 10 host.

The strange thing is that starting Command Prompt with "Run as Administrator" on Windows 10 increases performance a lot - back to Windows 7 level. Using the "Legacy Console mode" checkbox only seems to have a minor effect.

See attached scripts and results.txt.
scripts.zip
results.txt

What's wrong / what should be happening instead:

Windows 10 Command Prompt performance for build_cmd.bat and build_gcc.batshould be the same as with Windows 7, or at least the same as Windows 10 Command Prompt running as Administrator.

(The problem is that running a 10 minute build script might take 20+ minutes on Windows 10)

Originally created by @kjarvel on GitHub (Feb 6, 2019). **Configuration** * CPU: Intel Core i5-4590 @ 3.30 GHz * Windows 7 Anti-Virus: Microsoft Security Essentials * Windows 10 Anti-Virus: Microsoft Windows Defender * Display 1920 x 1080, Scaling 100% * GCC Arm compiler gcc-arm-none-eabi-8-2018-q4-major-win32-sha2.exe from https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads **Windows build number:** - Windows 7 SP1: Microsoft Windows [Version 6.1.7601] - Windows 10 1809: Microsoft Windows [Version 10.0.17763.253] **What you're doing and what's happening:** With Windows 7, executing `build_gcc.bat` (1000 x gcc-arm-none-eabi) in Command Prompt takes 0:46. With Windows 10, the same script takes +78% longer time with default settings (01:22). With Windows 7, executing `build_cmd.bat` (1000 x cmd.exe x 20) in Command Prompt takes 01:48. With Windows 10, the same script takes +139% longer time with default settings (04:18). Some observations: With Windows 10, some computers show heavy (25-40%) GPU load when Command Prompt is scrolling. A Windows 7 Virtual Machine running `build_cmd.bat` in Virtual Box on a Windows 10 host outperforms the Windows 10 host. The strange thing is that starting Command Prompt with "Run as Administrator" on Windows 10 increases performance a lot - back to Windows 7 level. Using the "Legacy Console mode" checkbox only seems to have a minor effect. See attached scripts and `results.txt`. [scripts.zip](https://github.com/Microsoft/console/files/2836535/scripts.zip) [results.txt](https://github.com/Microsoft/console/files/2836536/results.txt) **What's wrong / what should be happening instead:** Windows 10 Command Prompt performance for `build_cmd.bat` and `build_gcc.bat`should be the same as with Windows 7, or at least the same as Windows 10 Command Prompt running as Administrator. (The problem is that running a 10 minute build script might take 20+ minutes on Windows 10)
claunia added the Product-ConhostIssue-BugNeeds-Tag-FixArea-PerformancePriority-1 labels 2026-01-30 21:55:07 +00:00
claunia commented 2026-01-30 21:55:09 +00:00
Author
Owner
Copy Link

@kjarvel commented on GitHub (Jun 9, 2020):

Update one year later:

  • CPU: Intel Core i5-4590 @ 3.30 GHz
  • Windows 7 SP1: Microsoft Windows [Version 6.1.7601]
  • Windows 10 1909: Microsoft Windows [Version 10.0.18363.836]

build_cmd.bat

  • Windows 7, Command Prompt = 01:34
  • Windows 10, Command Prompt = 02:47
  • Windows 10, Windows Terminal Version 1.0.1401.0 = 02:36
@kjarvel commented on GitHub (Jun 9, 2020): Update one year later: * CPU: Intel Core i5-4590 @ 3.30 GHz * Windows 7 SP1: Microsoft Windows [Version 6.1.7601] * Windows 10 1909: Microsoft Windows [Version 10.0.18363.836] build_cmd.bat - Windows 7, Command Prompt = 01:34 - Windows 10, Command Prompt = 02:47 - Windows 10, Windows Terminal Version 1.0.1401.0 = 02:36
claunia commented 2026-01-30 21:55:09 +00:00
Author
Owner
Copy Link

@LuanVSO commented on GitHub (Aug 31, 2020):

did you try disabling windows defender real time protection to measure the performance?

@LuanVSO commented on GitHub (Aug 31, 2020): did you try disabling windows defender real time protection to measure the performance?
claunia commented 2026-01-30 21:55:09 +00:00
Author
Owner
Copy Link

@kjarvel commented on GitHub (Aug 31, 2020):

did you try disabling windows defender real time protection to measure the performance?

Yes, see the column named "Anti-virus" in results.txt.

@kjarvel commented on GitHub (Aug 31, 2020): > did you try disabling windows defender real time protection to measure the performance? Yes, see the column named "Anti-virus" in results.txt.
claunia commented 2026-01-30 21:55:10 +00:00
Author
Owner
Copy Link

@iamsergio commented on GitHub (Nov 26, 2020):

Is this specific to gcc or also observable with MSVC ?

@iamsergio commented on GitHub (Nov 26, 2020): Is this specific to gcc or also observable with MSVC ?
claunia commented 2026-01-30 21:55:10 +00:00
Author
Owner
Copy Link

@kjarvel commented on GitHub (Nov 28, 2020):

Is this specific to gcc or also observable with MSVC ?

See build_cmd.bat and the results for build_cmd.bat in results.txt. It does not use gcc.

@kjarvel commented on GitHub (Nov 28, 2020): > Is this specific to gcc or also observable with MSVC ? See build_cmd.bat and the results for build_cmd.bat in results.txt. It does not use gcc.
claunia commented 2026-01-30 21:55:10 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Nov 22, 2021):

You know, this is weird. I'd be fairly sure that checking the "use legacy console" checkbox would remove the issue, if it was something in the Console v2 codebase. That's pretty literally the exact code from the Windows 7 build, with only minor modifications to get it loaded into the v2 console.

We've been making pretty constant perf improvements over the years (case in point: https://github.com/microsoft/terminal/issues/1064#issuecomment-618024330). At this point, the Terminal is generally faster than the Console at all.

If you're still seeing this, would you mind trying to trace your build (or at least part of it) with WPA? I think we'd all be curious to see what the hot paths are.

@zadjii-msft commented on GitHub (Nov 22, 2021): You know, this is weird. I'd be fairly sure that checking the "use legacy console" checkbox would remove the issue, if it was something in the Console v2 codebase. That's pretty literally the exact code from the Windows 7 build, with only minor modifications to get it loaded into the v2 console. We've been making pretty constant perf improvements over the years (case in point: https://github.com/microsoft/terminal/issues/1064#issuecomment-618024330). At this point, the Terminal is generally faster than the Console at all. If you're still seeing this, would you mind trying to trace your build (or at least part of it) with WPA? I think we'd all be curious to see what the hot paths are.
claunia commented 2026-01-30 21:55:10 +00:00
Author
Owner
Copy Link

@kjarvel commented on GitHub (Nov 22, 2021):

Thanks for the response.
Yes, I'm also guessing that it does not have to do with the Console itself, but some underlying limitation.
I once again tried the original bat file 'build_cmd.bat' that is attached in 'scripts.zip' - on a brand new computer.

You can easily try this yourself, it requires no external dependencies, and you will see the same results.
Since you can also try this bat file within 3 minutes (1 minute on Win7) I ask you to trace it with WPA, because I don't know what that is, or how to use it.

My results now in 2021, performed on the same computer:

  • Windows 11: ~3 minutes to complete build_cmd.bat
  • Windows 7: ~1:30 to complete build_cmd.bat

Conclusion: Windows 7 runs the script twice as fast, even when running in a Virtual machine, on the same computer.

See attached video. Windows 7 to the left. Windows 11 to the right:
win7_vs_win11_2021.zip

@kjarvel commented on GitHub (Nov 22, 2021): Thanks for the response. Yes, I'm also guessing that it does not have to do with the Console itself, but some underlying limitation. I once again tried the original bat file 'build_cmd.bat' that is attached in 'scripts.zip' - on a brand new computer. You can easily try this yourself, it requires no external dependencies, and you will see the same results. Since you can also try this bat file within 3 minutes (1 minute on Win7) I ask you to trace it with WPA, because I don't know what that is, or how to use it. My results now in 2021, performed on the same computer: - Windows 11: **~3** minutes to complete build_cmd.bat - Windows 7: **~1:30** to complete build_cmd.bat Conclusion: Windows 7 runs the script twice as fast, even when running in a Virtual machine, on the same computer. See attached video. Windows 7 to the left. Windows 11 to the right: [win7_vs_win11_2021.zip](https://github.com/microsoft/terminal/files/7584892/win7_vs_win11_2021.zip)
claunia commented 2026-01-30 21:55:10 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Oct 10, 2024):

GCC should hopefully run a lot better now, in particular in Windows 11 24H2 (build 26100):
Image

I believe the reason Windows 10 is slower than Windows 7 is because conhost renders its content with GDI while holding the console lock (= synchronously, blocking all console calls). Windows 7 still had a proper GDI implementation and so the time spent holding the lock was "short". As you probably know, GDI got replaced in Windows 8 and so now it spents more time blocking output. The next version of Windows 11 should contain a version of conhost that renders its content asynchronously which should further boost the performance.

Unfortunately, it'll not increase performance of very short prints, because the stdout pipe on Windows is fully synchronous by design and will block until the entire cross-process round-trip is done. This puts a, if I'm completely straight, genuinely laughable limit of somewhere around 50k ops/sec (56K modems, now also on your PC!). That's not too surprising, I think, since 20us is roughly how long it takes to wake up & switch applications in any modern scheduler. But it's bad, really bad, and it's always been like that on Windows. The fix is to do async writes, which is a lofty goal given the risks. I hope I can pursue that in time for the next big Windows update.

In any case, I'll be closing this issue for now.

@lhecker commented on GitHub (Oct 10, 2024): GCC should hopefully run a lot better now, in particular in Windows 11 24H2 (build 26100): ![Image](https://github.com/user-attachments/assets/2375bad7-ec4c-4ecb-8c8b-6b0178ca00b4) I believe the reason Windows 10 is slower than Windows 7 is because conhost renders its content with GDI while holding the console lock (= synchronously, blocking all console calls). Windows 7 still had a proper GDI implementation and so the time spent holding the lock was "short". As you probably know, GDI got replaced in Windows 8 and so now it spents more time blocking output. The next version of Windows 11 should contain a version of conhost that renders its content asynchronously which should further boost the performance. Unfortunately, it'll not increase performance of very short prints, because the stdout pipe on Windows is fully synchronous by design and will block until the entire cross-process round-trip is done. This puts a, if I'm completely straight, genuinely laughable limit of somewhere around 50k ops/sec (56K modems, now also on your PC!). That's not too surprising, I think, since 20us is roughly how long it takes to wake up & switch applications in any modern scheduler. But it's bad, really bad, and it's always been like that on Windows. The fix is to do async writes, which is a lofty goal given the risks. I hope I can pursue that in time for the next big Windows update. In any case, I'll be closing this issue for now.
claunia commented 2026-01-30 21:55:11 +00:00
Author
Owner
Copy Link

@kjarvel commented on GitHub (Jan 1, 2025):

Update 6 years later:

  • CPU: AMD Ryzen 5 3400G @ 3.70 GHz
  • Windows 7 SP1: Microsoft Windows [Version 6.1.7601]
  • Windows 11 24H2: Microsoft Windows [Version 10.0.26100.2605]

build_cmd.bat

  • Windows 7, Command Prompt = 01:11
  • Windows 11, Windows Terminal Version 1.21.3231.0 = 02:50

So, no improvement (for short prints as @lhecker suspected).

@kjarvel commented on GitHub (Jan 1, 2025): Update 6 years later: * CPU: AMD Ryzen 5 3400G @ 3.70 GHz * Windows 7 SP1: Microsoft Windows [Version 6.1.7601] * Windows 11 24H2: Microsoft Windows [Version 10.0.26100.2605] `build_cmd.bat` * Windows 7, Command Prompt = 01:11 * Windows 11, Windows Terminal Version 1.21.3231.0 = 02:50 So, no improvement (for short prints as @lhecker suspected).
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 Area-Performance Issue-Bug Needs-Tag-Fix Priority-1 Product-Conhost
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#554
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?