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

vim slower to open/close in conhost v2 compared to v1 #5549

New Issue
Open
opened 2026-01-31 00:15:55 +00:00 by claunia · 3 comments
claunia commented 2026-01-31 00:15:55 +00:00
Owner
Copy Link

Originally created by @malxau on GitHub (Dec 13, 2019).

Environment

Windows build number: 17763
Windows Terminal version (if applicable): N/A, conhost only

Any other software? Vim for Windows, tested with 7.4-8.1

Steps to reproduce

Open a CMD window with a shortcut that specifies a large window buffer. The default in RS5 appears to be 9000, which is sufficient. Use the command line vim to open a random text file and observe startup time. Quit vim and observe exit time.

(Note that vim has a startup time debugging facility - run "vim --startuptime logfile filetoopen" and it will report the time spent in various phases of startup to the log file.)

Expected behavior

Expecting performance of open/close to be more in line with the legacy console. Note that the change to default to 9000 lines of history is also causal.

Actual behavior

Vim appears to take around a second or two to start and a second or two to exit, which appears to be saving and restoring the console screen buffer, when using conhost v2. This does not occur with v1, and can be mitigated by reducing the screen buffer size.

Originally created by @malxau on GitHub (Dec 13, 2019). # Environment ```none Windows build number: 17763 Windows Terminal version (if applicable): N/A, conhost only Any other software? Vim for Windows, tested with 7.4-8.1 ``` # Steps to reproduce Open a CMD window with a shortcut that specifies a large window buffer. The default in RS5 appears to be 9000, which is sufficient. Use the command line vim to open a random text file and observe startup time. Quit vim and observe exit time. (Note that vim has a startup time debugging facility - run "vim --startuptime logfile filetoopen" and it will report the time spent in various phases of startup to the log file.) # Expected behavior Expecting performance of open/close to be more in line with the legacy console. Note that the change to default to 9000 lines of history is also causal. # Actual behavior Vim appears to take around a second or two to start and a second or two to exit, which appears to be saving and restoring the console screen buffer, when using conhost v2. This does not occur with v1, and can be mitigated by reducing the screen buffer size.
claunia added the Help WantedProduct-ConhostIssue-TaskNeeds-ReproArea-Performance labels 2026-01-31 00:15:55 +00:00
claunia commented 2026-01-31 00:15:56 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Dec 14, 2019):

I might be wrong, but I suspect this could be the result of color conversions. The new conhost supports 24-bit RGB colors, while vim is using an old API that can only handle a palette of 8 colors. This means the API has to run a potentially complicated color conversion operation to convert each RGB attribute into an equivalent palette entry. And it has to do that 9000 * 80 times (or thereabouts).

That's actually something I've been wanting to look at for a while now, because I had an idea for how it could be optimised. But that's assuming the color conversions are actually the problem here.

@j4james commented on GitHub (Dec 14, 2019): I might be wrong, but I suspect this could be the result of color conversions. The new conhost supports 24-bit RGB colors, while vim is using an old API that can only handle a palette of 8 colors. This means the API has to run a potentially complicated color conversion operation to convert each RGB attribute into an equivalent palette entry. And it has to do that 9000 * 80 times (or thereabouts). That's actually something I've been wanting to look at for a while now, because I had an idea for how it could be optimised. But that's assuming the color conversions are actually the problem here.
claunia commented 2026-01-31 00:15:56 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Dec 16, 2019):

Thanks for filing this Malcolm 😄 Hopefully we'll be able to get a trace on this and figure out what particularly is causing this lag.

Fundamentally, vim shouldn't be saving and restoring the buffer on launch like this - it should really just be creating a new buffer, either the alt buffer or a full blown console buffer (via the API). I'm sure patching vim to just not do that would make a substantial improvement here, but we should be doing better even without that fix.

If we hold all other things constant (read: buffer size), then simply upgrading from v1 to v2 shouldn't have a dramatic decrease in console performance. I know @miniksa loves working on these sorts of things so I'll tag him here too.

@zadjii-msft commented on GitHub (Dec 16, 2019): Thanks for filing this Malcolm 😄 Hopefully we'll be able to get a trace on this and figure out what particularly is causing this lag. _Fundamentally_, vim shouldn't be saving and restoring the buffer on launch like this - it should really just be creating a new buffer, either the alt buffer or a full blown console buffer (via the API). I'm sure patching vim to just _not_ do that would make a substantial improvement here, but we should be doing better even without that fix. If we hold all other things constant (read: buffer size), then simply upgrading from v1 to v2 shouldn't have a dramatic decrease in console performance. I know @miniksa loves working on these sorts of things so I'll tag him here too.
claunia commented 2026-01-31 00:15:56 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jun 8, 2020):

I do not have enough statistical power to draw a conclusion, but I've got some fun numbers to look at all the same.

Methodology

I'm using an application on my phone called "Is it Snappy?", which takes high-speed video and lets you scrub frame by frame to mark "input" and "output" frames. It then tells you the time delta between them.

I launched vim in conhost (Vibranium inbox), OpenConsole (after #6358) and legacy v1.

Parameters:

  • Buffer size: 120x9001
  • Shell: CMD
  • Input mark: First frame in the video where "vim" appears in the titlebar (last thing CMD does before executing)
  • Output mark: First frame where 1 (the line number) appears in the top left of my buffer.

Possibly confounding factor: Openconsole is not built with the optimization or PGO instrumentation from the Windows build; it may be faster when reingested? To combat this, I built the OpenConsole solution at the point at which Vibranium was shipped.

(I listed this factor before running trials; it did not matter.)

Trials

trial v1 vb(inbox) vb(openconsole) #6358
1 216ms 349ms 382ms 382ms
2 232ms 382ms 366ms 399ms
3 199ms 382ms 349ms 349ms

image

@DHowett commented on GitHub (Jun 8, 2020): I do not have enough statistical power to draw a conclusion, but I've got some fun numbers to look at all the same. ### Methodology I'm using an application on my phone called "Is it Snappy?", which takes high-speed video and lets you scrub frame by frame to mark "input" and "output" frames. It then tells you the time delta between them. I launched vim in conhost (Vibranium inbox), OpenConsole (after #6358) and legacy v1. Parameters: * Buffer size: 120x9001 * Shell: CMD * Input mark: First frame in the video where "vim" appears in the titlebar (last thing CMD does before executing) * Output mark: First frame where `1` (the line number) appears in the top left of my buffer. Possibly confounding factor: Openconsole is not built with the optimization or PGO instrumentation from the Windows build; it may be faster when reingested? To combat this, I built the OpenConsole solution at the point at which Vibranium was shipped. (I listed this factor before running trials; it did not matter.) ### Trials trial|v1|vb(inbox)|vb(openconsole)|#6358 -|-|-|-|- 1|216ms|349ms|382ms|382ms 2|232ms|382ms|366ms|399ms 3|199ms|382ms|349ms|349ms ![image](https://user-images.githubusercontent.com/189190/84073572-f1c22b00-a985-11ea-8f99-263c919bc43b.png)
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 Help Wanted Issue-Task Needs-Repro 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#5549
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?