Repository navigation
Extremely slow performance when processing virtual terminal sequencesΒ #10462
Description
Windows Terminal version (or Windows build number)
1.8.1521.0
Other Software
No response
Steps to reproduce
Using any command line utility that produces virtual terminal sequences for setting the colors of individual characters, the performance of the terminal drops by a factor of around 40.
To measure this effect precisely, you can use the F2 key in termbench and observe the performance difference between color-per-character output and single-color output:
https://github.com/cmuratori/termbench/releases/tag/V1
Expected Behavior
Despite the increased parsing load, modern CPUs should not have a problem parsing per-character color escape codes quickly. I would expect the performance of the terminal to be able to sustain roughly the same frame rate with per-character color codes as without, and if there was a performance drop, I wouldn't expect it to be anything close to 40x.
Actual Behavior
The speed of per-character color output is 40x slower than the speed of single-color output.
Activity
CoreyDotCom commentedon Jun 19, 2021
Note that this is a clone of #10362 which was closed by original submitter. As the original bug report was valid it should have been remained open, especially after quite a few suggestions were provided as to how to improve matters. Feel free to reopen original tracking issue and close this duplicate if appropriate. Thank you for the work that you guys do on this project.
[-]https://github.com/microsoft/terminal/issues/10362[/-][+]Extremely slow performance when processing virtual terminal sequences[/+]DHowett commentedon Jun 19, 2021
Thanks for re-opening this! Itβs definitely valuable for us to be tracking it, and the ideas suggested in the original thread are good ones that are worth considering. We also have #10461 tracking specific requests from #10362.
lhecker commentedon Jun 19, 2021
Personally I'd like to also welcome Casey Muratori (@cmuratori) and MΔrtiΕΕ‘ MoΕΎeiko (@mmozeiko) back to give any comments if they wish to do so. Of course it'd be entirely understandable if they don't. I believe I can speak for the terminal team, when I say that we want to keep the door to our community open and welcome any civil discourse.
I see the comment regarding slow VT parsing again, but I hope you consider that performance of OpenConsole (aka future conhost) has already improved about 4-5x in the last year. With upcoming conhost versions, or the current OpenConsole, you can expect to see a throughput improvement from 4MB/s to about 16-20MB/s for termbench. I know this isn't 270MB/s, but it's a significant improvement regardless, despite keeping all the backwards-compatibility, etc.
For instance - referring to the mentioned offenders:
ATTR_ROW::InsertAttrRunswas entirely rewritten and doesn't allocatestd::vectors anymore in Introduce til::rle - a run length encoded vectorΒ #10099_ViewportToStringdoesn't even exist anymore and was replaced in Move ConPTY to use til::bitmapΒ #5024We're now working on improving
_SetGraphicsRenditionRGBColorin #10426, which will improve performance for termbench by another 20-25%. FYI: Chester Liu (@skyline75489) is working on this entirely in their spare time! (...and the PR is in fact not finished yet. It'll likely feature more improvements once it's done.)Here's a flamegraph of OpenConsole for termbench:
The render output thread is highlighted in blue.
_SetGraphicsRenditionRGBColoris being hovered.If you have concrete ideas what to improve (and optionally how) to speed up OpenConsole's VT performance further, please let us know and we'll get to it. Promise! Contributions are especially welcome at any time!
mmozeiko commentedon Jun 19, 2021
Is there a possibility we (outside of Microsoft) can get some documentation or specification on console driver interface -
\\Device\\ConDrv\\Server, structures incondrv.handconmsgl*.hfiles ?DHowett commentedon Jun 19, 2021
Fair question! We should definitely have some docs on the driver interface, since we're now an open source project that is using an underdocumented OS fixture...
Right now the best we have is in the ApiDispatcher and some of the "load bearing code" comments across the codebase. That's not great. I'll see what we can do about that!
lhecker commentedon Jun 19, 2021
MΔrtiΕΕ‘ MoΕΎeiko (@mmozeiko) Sure! Let's continue that discussion here: #10463
skyline75489 commentedon Jun 26, 2021
skyline75489 commentedon Jun 26, 2021
mmozeiko commentedon Jun 26, 2021
skyline75489 commentedon Jun 26, 2021
45 remaining items
DHowett commentedon Nov 2, 2021
Ah, I minimized the comments above before I locked the thread. They can be expanded with the "Show comment" link at the righthand side for now, but I'll also go through and unminimize some of them. Sorry!
I like that. You're right, of course. These are all really good points for us to think about. π
plasticalligator commentedon Jan 7, 2024
christianparpart commentedon Jan 7, 2024