Open CoreyDotCom opened 3 years ago
CoreyDotCom
commented
3 years ago Note that this is a clone of https://github.com/microsoft/terminal/issues/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.
DHowett
commented
3 years ago 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
commented
3 years ago Personally I'd like to also welcome @cmuratori and @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::InsertAttrRuns was entirely rewritten and doesn't allocate std::vectors anymore in #10099_ViewportToString doesn't even exist anymore and was replaced in #5024We're now working on improving _SetGraphicsRenditionRGBColor in #10426, which will improve performance for termbench by another 20-25%. FYI: @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. _SetGraphicsRenditionRGBColor is 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
commented
3 years ago Is there a possibility we (outside of Microsoft) can get some documentation or specification on console driver interface -\\Device\\ConDrv\\Server, structures in condrv.h and conmsgl*.h files ?
DHowett
commented
3 years ago 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
commented
3 years ago @mmozeiko Sure! Let's continue that discussion here: #10463
skyline75489
commented
3 years ago I'm hiding this comment because some people find it dismissive and feel that I'm finding excuses. I'm honestly just trying to find the truth.
skyline75489
commented
3 years ago I'm hiding this comment because some people find it dismissive and factually incorrect.
mmozeiko
commented
3 years ago Modern AAA games also use up to all of CPU cores (with up to 100% load) and almost all of the GPU memory & computing power at its disposal. People don't really expect this kind of resource usage from a terminal application. One of the key goal of the terminal is I believe to minimize the resource usage.
What kind of argument is this?!? You are completely missing the point. Are you saying it is unfair to compare to AAA game because terminal should or cannot use same kind of power/load? If answer is yes - then this project is failing. Because it is doing exactly that - using 100% of same load/power as AAA game, but doing far simpler rendering. In fact it is actually using more - here's comparison running Overwatch.exe vs WindowsTerminal.exe with termbench: https://i.imgur.com/7VVWh9W.png who is using more cpu? As far as I can tell: 3.22+1.03 > 1.19
Obviously terminal should not use 100% load of cpu core or gpu to render fullscreen of text. I have demonstrated that with real code (1000+fps rendering) which Casey also was explaining. Limit it to composition rate, and you'll have mostly idle cpu core.
And yes, sure the other part of code - actual layout of characters will take extra time. But doing that in fixed monospaced grid is far from complexity of text layout in browsers or word processors that you and others like to mention a lot. Like really really far away, super far away. Having extra constraints like that makes problem much simpler. Which Casey is working on, and in current state it can do much of unicode and still runs in sub-millisecond per frame (not completely finished, but there's no doubt it'll work with same kind of performance).
I may be saying things a bit out of line here - but if you don't know how hard (or easy) is to do text layout for unicode, then you should simply say that. Instead of claiming it is hard (because you don't know that). For example, I don't know that, because I've never done full-blown unicode rendering or looked into details. But I trust other people / expert opinion who have done it, and they say it is completely doable in this situation.
But the uniqueness of the terminal is the way people sometimes use it for lots of changing text.
This sentence makes me upset way more than anything that was said before. Do you understand that any simple (not "modern AAA game") is outputting more than 2 MILLION pixels (on 1080p screen) that changes EVERY single frame and each of them can have UNIQUE color. That is more than 120 MILLION unique pixels per second. But here we are again still discussing why outputting something like 30 thousand of text characters difficult or unique...
skyline75489
commented
3 years ago I'm hiding this comment because it does not contain useful information for most people.
lhecker
commented
3 years ago @skyline75489 @mmozeiko I've already built a prototype for unicode text rendering using a glyph atlas. I'm currently working on integrating it into our existing code in whatever time I can spare. The performance you get out of it is extremely impressive. I'm doubtful that the comparison with Overwatch is anywhere near fair, especially if you showed a couple more columns there. But regardless, you certainly won't have to convince me to build it that way anymore, as I've been determined to build it that way for quite a while now. All of this is and will be tracked #10461. And again I should mention that this isn't just to be considered, it's in fact on the backlog.
A performance drop of ~40x from maximum theoretical framerate, when drawing colored output using termbench, should always be considered expected, as termbench outputs about ~40x as much text, when coloring is enabled. I'm not saying we can't be even better than that, but it's logical that a drop like that should at least, in the most literal sense, be expected. I think it's loosely approximately the same drop in other terminals. We'll now just make sure that we don't drop the framerate below anything in the hundreds (or thousands?), because that's definitely something other terminals don't do.
Either way I feel like this discussion is starting to heat up again. I'd like to note a couple things:
Anyways, as I said before, you won't have to convince me of it, the person who'll actually build it. I'm already convinced. Instead this issue will be exclusively about VT performance and I'd like to exclusively see:
nico-abram
commented
3 years ago This is sadly not the truth at the moment. I've tested a bunch of terminals, including GNOME Terminal, rxvt, tilix and Alacritty (perhaps the fastest terminal emulator for the moment being), they both show significant performance drop with heavy VT load. See alacritty/alacritty#5278 for details. The maintainer of Alacritty seems to concur with this conclusion: the performance drop with massive VT load is reasonable & expected.
To be clear: You are saying this can be the case for just the rendering part, but that it can be slower because of VT processing (Which as I understand it, happens mostly in conhost)?
Also, is it possible Alacritty (And all the other terminals you may have tried on windows) are being slowed down by an older version of conhost and slower processing of VT sequences in it than the current OpenConsole? (Possibly making it an unfair comparison)
skyline75489
commented
3 years ago @Nicholas-Baron I don’t quite get it what you are asking. I was testing those Linux terminals on barebone Linux machine.
Which as I understand it, happens mostly in conhost
This is not correct. I think you don’t quite know the full picture of ConPTY. VT processing happens in both conhost & Windows Terminal. This is also true with other terminals on Windows that uses ConPTY. If I have to guess the ratio, I’d probably say 60% in conhost and 40% in the terminal? Just a rough guess. Not precise numbers.
Nicholas-Baron
commented
3 years ago @Nicholas-Baron I don’t quite get it what you are asking. I was testing those Linux terminals on barebone Linux machine.
@skyline75489, I think you have the wrong person.
skyline75489
commented
3 years ago Yep sorry. On my phone 😅. @nico-abram
AnuthaDev
commented
3 years ago lhecker
commented
3 years ago @AnuthaDev We‘re quite aware about the code and are extremely happy about what was created there. I mean it seriously: It sets a great goal for us to strive for. Unfortunately the code is intentionally GPLv2 licensed and we‘ll honor this wish entirely. As such no one at Microsoft will ever look at either of the links.
I‘m the person who‘s tasked with building an equivalent solution and you may subscribe to https://github.com/microsoft/terminal/issues/10461 to get updates of my progress. Unfortunately our existing project isn’t straight forward to modify the same way we could build a terminal from scratch. A lot of parts of this project must be rewritten and as such it‘ll take a bit for us to catch up. But we will - it’s only a matter of time.
AnuthaDev
commented
3 years ago @lhecker I appreciate your response :)
Unfortunately the code is specifically GPLv2 licensed to prevent us from using it and we‘ll honor this wish entirely. As such no one at Microsoft will ever look at either of the links.
I know very little about licensing, but I believe the author can relicense their work, no?
So, maybe you can talk to the author about that🤔🤔
Though from the phrasing you used:
"licensed to prevent use from using it"
It doesn't seem like the author would be too keen on changing the license😬
Other than that, I appreciate the work of the terminal team😊 (and try to contribute what I can)
(Also: The linked video didn't mention anything about memory usage, I hope implementing a similar solution doesn't use unreasonable amounts of RAM)
lhecker
commented
3 years ago @AnuthaDev I‘ve talked with the author before and they made it abundantly clear they don’t wish to ever speak with us again. They‘re entirely welcome to return and take part in this project‘s discourse of course… I‘d be delighted if that was the case!
I think I’ve got a pretty good plan to reduce the memory consumption to an absolute minimum. Once I can prove that it works in practice I‘ll scratch that concern off of the list in the other issue.
skyline75489
commented
3 years ago Thanks @AnuthaDev for the interest in this project!
As a witness/participant of the entire “extreme slow VT performance” affair, I found that it has turned into some sort of complete opposition against this project and the console team members (be it on Twitter or GitHub), which makes me feel very sad personally.
I fully believe that the intention behind #10362 is good. The author went through certain amount of effort and provided a reasonable suggestion. But due to the lacking of understanding, miscommunication happened, then it turned into a flame war between two groups of people. Every single sentence from the terminal people sounds like excuses. And people hate excuses.
At the end of the day, @lhecker took his time doing research and decided to take over the task to actually implement a better renderer. Mistakes are recognized. I have personally made false assumptions and so do other people. And I am sure no one is proud of their mistakes. After all these, some people still think that we at Microsoft are just so dumb and incompetent that we can’t make a proper terminal.
I am NOT an official member of the team. I can only speak on my own behalf. I think every contribution from everyone is welcomed here. But people do get defensive sometimes. I contribute to this project in my spare time for free. I am not getting paid. Yet I was harshly insulted on Twitter. You tell me how I might feel about it.
The official members of the team spend the last 5-6 years in this project. Despite all the discussions & comments everywhere, it’s up to them to actually improve this product. This isn’t just a hobby project. This is a commercial product which has a lots of regulation to follow, lots of limitations to suffer from. These sounds like excuses, but it’s the truth.
I totally get it how people can be frustrated. I was very frustrated with the terminal in the year 2019. Back then the performance is so bad that I can’t understand it. I personally filed several PRs to help improving the performance. As of today I think the terminal is performant enough for most cases. If you found it’s not fast enough for you, just file an issue.
In the end I am very sad about how this affair turned into. I am kindly asking people to be kind to each other and try to have the compassion & understanding when having conversations, to prevent it from becoming something even worse.
AnuthaDev
commented
3 years ago @skyline75489 Well, whatever happened was unfortunate, so, let's just not focus on it.
And the terminal is already pretty fast for me (other than slow startup and shutdown, but I'm pretty sure that's just how XAML apps are), I only commented because I thought it could be useful for anyone trying to solve this problem...
Kein
commented
3 years ago So, this might be of interest:
May be one day we will get terminal like this under Win that rivals nix one in performance while still being as feature rich. Until then, I guess, Windows Terminal is a compromise and a first stepstone in 20 years long journey.
skyline75489
commented
3 years ago @Kein the terminal showed in that video actually outperforms almost every single terminal out there, be it on Windows, Linux, or macOS. (Haven’t really test on macOS but I assume it’ll just be the same)
orcmid
commented
3 years ago @lhecker I appreciate your response :)
Unfortunately the code is specifically GPLv2 licensed [ ... ]
I know very little about licensing, but I believe the author can relicense their work, no?
I failed to check on the license before I followed that project. And I know too much about licensing. I need to unfollow that effort and confine my study to MS Terminal. I appreciate the constraints that MS Devs must operate under.
The original copyright holder can offer dual licenses but there is an ideology factor here. The holder could even make a private commercial license, but that would clash with MS Terminal code in the open. When there are already multiple contributors and not a single copyright holder, even those variations become more difficult. The ideological posture is insurmountable.
lackhoa
commented
3 years ago I am NOT an official member of the team. I can only speak on my own behalf. I think every contribution from everyone is welcomed here. But people do get defensive sometimes. I contribute to this project in my spare time for free. I am not getting paid. Yet I was harshly insulted on Twitter. You tell me how I might feel about it.
I'm not a lawyer but this seems like an off-topic rant?
dmitriid
commented
3 years ago @AnuthaDev We‘re quite aware about the code and are extremely happy about what was created there. I mean it seriously: It sets a great goal for us to strive for. Unfortunately the code is intentionally GPLv2 licensed and we‘ll honor this wish entirely. As such no one at Microsoft will ever look at either of the links.
Let's see:
Something tells me that:
Also something tells me that the half-a-dozen to a dozen of Microsoft developers working on Windows terminal:
Instead, you complain that his code that he didn't even need to write to prove his point, is GPL v2. I'm afraid you're provinf his point tenfold.
lhecker
commented
3 years ago @dmitriid You can read whatever you want into my message, but I wrote it in the most literal sense. The fact that it's "intentionally" GPLv2 licensed (and us being banned from accessing the repository by GitHub) is important here, as this shows the "intention" that we're being kindly asked to not use it. I don't consider this something bad. He has every single right to do that and I might actually do the same in his shoes. As such I consider your inflammatory comment as off-topic.
alabuzhev
commented
3 years ago Maybe I'm missing something obvious, but why is this a problem? There were discussions and youtube videos recently, demonstrating that conhost / WT are "slow" because piping gigabytes of text through them takes more time than through some other implementations. But why would anyone in their right mind do that in the first place? No one can read a gigabyte of text with their eyes, so why even bother printing it? Just because you can, doesn’t mean you should. Print a 50-character progress bar if you must and update it once per second, it's good enough. Who cares whether it's 5 or 5000 FPS in a console application?
Don't get me wrong, I totally agree that things that could be fast should be fast and the code at least should not juggle with temporary strings, waste CPU cycles and heat the room. But being correct is incomparably more important here than being fast, and by "being correct" I mean properly supporting Unicode, terminal features and all the existing conhost scenarios (yes, even if you don't like them and think they're redundant because *nix terminals never had them).
The current performance is generally acceptable outside of synthetic tests. The correctness is... not so acceptable. Improving performance for the sake of performance, now, at the expense of other areas, is hardly the right thing to do. Just saying.
bvisness
commented
3 years ago I believe this issue originally came up because performance was not acceptable in a real use case (building a small game in a terminal).
Generally though, when severe performance issues arise, it's important to spend some time addressing them. Severe slowdowns are rarely because a problem is fundamentally difficult; it's usually because something is wildly inefficient. Ideally, it's an isolated incident and you can make a quick fix. Less ideally, the issue arises out of the complexity of the system and is hard to address without sweeping changes. But if we're talking about a 100x to 1000x slowdown over a prototype solution, clearly that complexity is not inherent to the problem, and needs to be addressed.
So the work is worth doing either way. Either you get an easy win, or you tackle systemic issues that will hurt future work.
skyline75489
commented
3 years ago Thanks gentlemen for your insights of this particular issue. There's a lot of things done in the past month, and I think it's safe to say there will be more PRs targeted this area in the future (probably not from me, though).
There are too many discussions around the initial issue that some of them are largely deviated from what I think people should really care. Conhost is slow. WT is also relatively slow. That's why the initial issue came up. The old conhost is really really slow under heavy load. But in the meantime, both conhost and WT are also usable for most people under most scenarios. It's really not a black or white situation here.
We all want it to be fast, and I think we will try to make it faster without "the expense of other areas"
nico-abram
commented
3 years ago Maybe I'm missing something obvious, but why is this a problem? There were discussions and youtube videos recently, demonstrating that conhost / WT are "slow" because piping gigabytes of text through them takes more time than through some other implementations. But why would anyone in their right mind do that in the first place? No one can read a gigabyte of text with their eyes, so why even bother printing it? Just because you can, doesn’t mean you should. Print a 50-character progress bar if you must and update it once per second, it's good enough. Who cares whether it's 5 or 5000 FPS in a console application?
Don't get me wrong, I totally agree that things that could be fast should be fast and the code at least should not juggle with temporary strings, waste CPU cycles and heat the room. But being correct is incomparably more important here than being fast, and by "being correct" I mean properly supporting Unicode, terminal features and all the existing conhost scenarios (yes, even if you don't like them and think they're redundant because *nix terminals never had them).
The current performance is generally acceptable outside of synthetic tests. The correctness is... not so acceptable. Improving performance for the sake of performance, now, at the expense of other areas, is hardly the right thing to do. Just saying.
I think this is a false dichotomy, you do not necessarily lose features or are less correct just by being faster. Even if that were the case of the renderer, you could let users choose (Since you mentioned the videos and unicode, it was claimed at multiple points in the videos that WT actually has worse support for unicode than the prototype from the demo)
As a data point, someone showed that a good bit of the slowdown shown in the video came from the windows SDK replacing newlines in text mode stdout output because it did a bytewise copy (Instead of something like a 64bit sized copy or even SIMD) here https://github.com/ojdkbuild/tools_toolchain_sdk10_17763/blob/master/Source/10.0.17763.0/ucrt/lowio/write.cpp#L399-L410 . Now, that's not a windows terminal specific problem, but it does affect the speed of stdout text mode output, and does not have any effect in "features" or "correctness". I can think of multiple scenarios where you can output a good bit of data into a terminal. If you have a program logging things to a terminal, it could at some point end up printing a huge amount of data (Of course, this might be unintended or a bug). Or you could accidentally cat the wrong file which turned out to be huge, or you could have an application that makes heavy use of VT codes (Like a terminal text adventure game with colors, or something like https://github.com/ecumene/rust-sloth ). Regardless, this mostly serves as a stress test, even if you're not outputting hundreds of megabytes, smaller payloads would also be faster, and I'm not 100% sure but it wouldn't surprise me if optimizations like these resulted in less power usage for laptops and the like.
I'm also not convinced that your argument about prioritizing features is right. Many performance issues are arquitectural and have far-reaching consequences. If you completely ignore performance in favor of "features", you can easily end in either a "death by a thousand cuts" situation (Like overuse of std::string resulting in lots and lots of copies all over the place (I'm not claiming that's the case for WT, just giving an example) ), or you can end up tied to some high level arquitecture/design that is way slower than it needs to be, and changing it has far-reaching consequences.
zadjii-msft
commented
3 years ago I'm not gonna entertain more discussion of "is this valuable". Performance improvements are always valuable. The terminal is fast enough for most use cases, but not all, and we're gonna keep working on it.
Let's keep the discussion focused on concrete examples of how we can improve here. I'm gonna be very liberal with the "off topic" button here.
skyline75489
commented
3 years ago I've deleted my previous comment regarding the related works, because the content has become somewhat stale & outdated. Also I simply don't really want to remember the things from the past. It sometimes made me sick. If someone is still interested in this area, simply search for issues with the tag Area-Performance.
I was talking to someone and he made me realize that being silent is sometimes even worth than joining a fight. So I'm writing this to let people know that, the words you said on the Internet does have consequences. One of the consequences is that, I'm quitting this project as an outside contributor. I simply don't have the energy & fun any more. Being one of the active contributors specifically in the performance area, I was traumatized by some of the harsh words personally. And I can't fight back, because that would just backfire immediately. Quitting is my easy way out.
Rest assured, the official team members will continue their fantastic work to make WT faster & better everyday. In a way, everyone wins.
Mike, if you see this, maybe mark this as off-topic, I don't know. Do what you like. No hard feelings :).
Dustin, if you see this, I was only asking for that perspective because I was afraid that you might forget about me if I'm no longer active in this repo.
ndwork
commented
3 years ago @lhecker If it takes longer to modify than it does to rewrite from scratch, why not just write a new one from scratch?
How much time are we talking about here? Muratori built his in less than two days. Your statement comes dangerously close to once again claiming the project is a doctoral thesis.
See a related comment from Muratori here: https://twitter.com/cmuratori/status/1454152344522805249?s=20
I‘m the person who‘s tasked with building an equivalent solution and you may subscribe to #10461 to get updates of my progress. Unfortunately our existing project isn’t straight forward to modify the same way we could build a terminal from scratch. A lot of parts of this project must be rewritten and as such it‘ll take a bit for us to catch up. But we will - it’s only a matter of time.
christianparpart
commented
3 years ago @lhecker If it takes longer to modify than it does to rewrite from scratch, why not just write a new one from scratch?
Valid question - but relevant? But keep in mind that backwards compatibility to legacy systems is still a thing and that rewriting the world is not always leading to more stable or faster code. This is usually a typical symptom for startups :)
How much time are we talking about here? Muratori built his in less than two days. Your statement comes dangerously close to once again claiming the project is a doctoral thesis.
Keep in mind that refterm is having fundamental design flaws. This two-day project is merely comparable to an improved in-game quake terminal, but not a terminal emulator. I would really like threads like these to stay focused, i.e. let's not even start talking about that on GH (use Twitter if you like). Let's keep github issues technically focused. I hope i'm not alone on that standpoint but I'd feel sincerely sad if threads have to be locked due to posts like these as then outsiders cannot give valuable feedback, that I still try to provide.
See a related comment from Muratori here: https://twitter.com/cmuratori/status/1454152344522805249?s=20
Unproven unfounded claims. Let's please not spam non-constructive links nor comments (anywhere, actually). :)
dmitriid
commented
3 years ago @christianparpart
Keep in mind that refterm is having fundamental design flaws.
And those are?
This two-day project is merely comparable to an improved in-game quake terminal, but not a terminal emulator.
If you followed refterm, you'd know it's not the case.
Let's keep github issues technically focused.
Let's. Casey Muratori built a renderer that supports the following, quote:
Quite a lot for "an improved in-game quake terminal", don't you think? And uses the same technologies that Windows Terminal uses: conhost etc. (as of v2 it doesn’t even try to bypass them).
Unproven unfounded claims.
They have been both proven and founded
I'd feel sincerely sad if threads have to be locked due to posts like these as then outsiders cannot give valuable feedback
Valuable feedback has been provided, with proof, and summarily dismissed. What you see is the inevitable fallout.
Of course a fully-featured terminal is more than just a renderer. But when a 20-person team at a trillion-dollar corporation can’t figure out how to render anything beyond ascii using the same techniques that one person used to implement everything in the list above, it makes you wonder, it does.
christianparpart
commented
3 years ago Keep in mind that refterm is having fundamental design flaws.
And those are?
I'll keep it short: try this with that design: https://twitter.com/iamc9p7/status/1454759288547811329 - again, let's make a full-stop here or otherwise I'm afraid this thread will be closed. If you'd like continue the discussion, just message me anywhere... else ;)
dmitriid
commented
3 years ago @christianparpart
And those point at "fundamental design flaws" how, exactly? " Let's keep github issues technically focused. Unproven unfounded claims. Let's please not spam non-constructive links nor comments" ©
There's an implicit claim in there that implementing these codes will:
Each of these "but you cannot do something" have been debunked again and again by Casey implementing them. At some point you, or, you know, the 20-person team at the trillion dollar company is supposed to start paying him for doing their job.
dmitriid
commented
3 years ago BTW. There's now a 5-part series on refterm over here: https://www.youtube.com/watch?v=pgoetgxecw8&list=PLEMXAbCVnmY6zCgpCFlgggRkrp0tpWfrn&index=1 It's not GPL, it doesn't show code, so even Microsoft emplyees can watch those without reprecussions.
christianparpart
commented
3 years ago Just try to implement what I was asking for. I may surely be wrong. But sticking to the chosen design will make it really hard to implement any of these that I was asking for. - Just try it. let's stop chatting here and just try it. I am pretty sure everyone will welcome any actual contribution rather than just talking. I also know the 5-part series as part of his Kickstarter promotion. It's just describing what he did, not how to make that code implement what I was asking for or how to get real world terminal apps running. Just try it. And again, please email me with your concerns or through any other channel. This does not belong here.
uspasojevic96
commented
3 years ago BTW. There's now a 5-part series on refterm over here: https://www.youtube.com/watch?v=pgoetgxecw8&list=PLEMXAbCVnmY6zCgpCFlgggRkrp0tpWfrn&index=1 It's not GPL, it doesn't show code, so even Microsoft emplyees can watch those without reprecussions.
Oh will you stfu already, here are the keypoints:
lhecker
commented
3 years ago Please keep this issue focused on the technical aspects. I've only been working on this issue a few weeks so far. I hope you all understand that many other users had equally valid concerns and feature requests before this issue came up and had to be implemented first.
I'll let everyone know here once this situation has improved in Windows Terminal. I‘m aiming for the 1.13 Preview release in December for a first change with a new text renderer.
Before that I'd like to mention that this first change doesn’t solve the termbench performance issue entirely nor increases the text throughout to anything over 20MB/s yet. These issues require more iterations to iron out and I'm planning to improve that situation within next year. Building a new terminal from scratch isn’t an option due to strong compatibility/legacy concerns of course.
ndwork
commented
3 years ago I am keeping this issue focused on technical aspects. Whether to work with a massive legacy code or start from scratch is a worthwhile technical question.
Building a new terminal from scratch isn’t an option due to strong compatibility/legacy concerns of course.
This doesn’t make sense to me. One can create something new that is backwards compatible. Actually, Microsoft has done this. Recall Word when .docx replaced .doc.
What backwards compatibility is causing the massive delay. Are these features desired? The purpose of terminal is (fundamentally) to display and receive text, is it not? How many lines of code are currently required to do this? Is this reasonable?
By your earlier statement, it would be easier to build a new one from scratch. Why not do that?
How many man hours will be required to create a terminal that compares to the performance of germbench? When do you expect to have such a terminal? Given that Muratori did this in less than 2 days, why is the extra time needed?
DHowett
commented
3 years ago We certainly handled the original issue poorly, and we're trying to do better.
Casey showed us, with his own particular brand of "showing," that our terminal emulator could be more performant.
Valuable feedback has been provided, with proof, and summarily dismissed.
We may not have taken the feedback seriously to begin with, but if it appears to have been completely dismissed then I am sorry.
Since July, we've begun work on a new renderer implementing the improvements Casey suggested and removed a number of performance bottlenecks along the way (resulting in a ~30% speed improvement for bulk text output and a ~15% speed improvement for VT parsing.) Yes, we move slowly. Whether that is a reasonable cause for community ire is not something I intend to address.
To @ndwork's point: the question of "evolution versus revolution" is a worthwhile one to ask. Why do we care so much about keeping what we have and not stopping to rewrite it? I can only answer from my perspective as the engineering lead here.
Unlike other folks, I'm just not in it to kill the old and replace it with the new. That's never been a winning strategy, has it? Everybody else seems like they're rolling out a new rewrite every year, or every two years, that has 20% of the features of the original and the team pretty much shuts down when they hear that users are (quelle surprise!) dissatisfied with their great new thing.
I feel like our approach, while slow, is at least measured.
Now. This is not really the appropriate venue to discuss:
It is the appropriate venue to discuss:
I'm leaving this issue unlocked. Let's work together to keep it on topic!
ndwork
commented
3 years ago Thank you for your response.
Why were so many comments deleted? It's hard to accept your communal statements when you discard so many of the comments. Indeed, it seems that my comment which you are addressing has been deleted. (Or, I don't really know how to use this messaging board, the comment is there, and I just don't see it.)
Perhaps the reason that the code is so difficult to improve is because of the dependencies. Is it the role of the Terminal to improve the console host? Or should Terminal just focus on being an excellent terminal. Which would serve Microsoft better? In my mind, retaining a manageable scope (making a good terminal) has much more valuable than minimally improving Windows by contributing to some massive underlying library.
I'm just not in it to kill the old and replace it with the new. That's never been a winning strategy, has it?
Based on this idea, Apple would still be using slow Motorolla chips. Instead, they moved to Intel (which Microsoft still uses) and have just recently exceeded Intel's capabilities (for laptops) with their own chips. In my own work, I routinely destroy old codes and replace them with new. By doing so regularly, I never build up too much technical debt. Instead, it's paid off daily, and the codes naturally adapt. Having said that, I'm not a lead of a product at Microsoft used by gazillions; I cannot comment intelligently on your situation. There may be great reasons not to do so; based on the above, I don't understand those reasons. And when one programmer can exceed the performance of a Microsoft product by factors of hundreds with less than two days of programming, I would stare that fear of change in the face, ask exactly what you're afraid of, and is there a way to mitigate that consequence while still achieving. Perhaps limiting the scope of the terminal and eliminating its dependency on the console host is a reasonable approach.
I offer the following statement by Isaacson in the biography on Jobs:
“One of Job's business rules was to never be afraid of cannibalizing yourself. " If you don't cannibalize yourself, someone else will," he said. So even though an Iphone might cannibalize sales of an IPod, or an IPad might cannibalize sales of a laptop, that did not deter him.”
Again, thank you for your response.
DHowett
commented
3 years ago (Or, I don't really know how to use this messaging board, the comment is there, and I just don't see it.)
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!
"...never be afraid of cannibalizing yourself..."
I like that. You're right, of course. These are all really good points for us to think about. :smile:
plasticalligator
commented
10 months ago The year is 2024 and Microsoft is still run by clowns too busy having meeting after meeting about useless shit to actually get any real work done while adamantly refusing to allocate any actual funding or resources to anyone capable. Congratulations Microcosm, you have somehow managed to turn something as simple as the Terminal into an exemplary metaphor for the downfall of society and the decaying mess we call the American Dream.
Or in simpler language: please stop shipping broken as hell products you illiterate leaded gasoline huffing imbeciles.
christianparpart
commented
10 months ago @plasticalligator I am a terminal emulator Developer myself (check Contour), since you mentioned a terminal to be "easy", I hereby invite you to contribute to make the product better. I truly believe that one can only judge about a stone when having sat on it for at least three years. So let's work together and make the terminal world great again. Go fork the product (Windows terminal or mine if you like) and prove your point.
Other than that, please let's be polite by all means. Happy New Year to y'all.
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.