I am annoyed about this because the kind of stuff you are saying is all I hear from programmers on the internet every day, and the result is that software keeps getting worse and worse, and everyone thinks they are doing great.
-
-
Replying to @Jonathan_Blow @Tyriar and
Like do you actually have any evidence, or even any vague pre-evidentiary reason to think that doing VT100 escape codes should in principle be slow for N == (number of text characters on a screen)? Or are you just picking that as a reason why the comparison is "unfair"
1 reply 0 retweets 5 likes -
Replying to @Jonathan_Blow @Tyriar and
because that's the first thing available you thought of, and if Casey had implemented VT100 escape codes, you would find some other reason it is "unfair"?
1 reply 0 retweets 5 likes -
He did implement some VT codes, the color demo at the end shows that. What he did not do was run the process through a pseudoterminal which is not native to Windows so it needs to run through the slow an emulation layer which I believe is the real problem here
3 replies 0 retweets 0 likes -
Replying to @Tyriar @Jonathan_Blow and
I'd like us to focus on the actual problem rather than "look at these thousands of frames, omg WT so slow". When conpty is slow, it will cause more frames to be rendered. If conpty is fast, less frames get rendered because everything is done already.
1 reply 0 retweets 0 likes -
[1/2] Hi Daniel. I thought it would be clear from the video, but I ran refterm both ways: with fast pipes off, it's running through conhost, so the entire super-slow Windows part _is running_. So the 10x speedup over Windows Terminal was _with_ super slow conhost.
1 reply 0 retweets 4 likes -
Replying to @cmuratori @Tyriar and
[2/2] The _additional_ 10x speed up with fast pipes (for 100x total) is what happens when you bypass conhost. So a simple way to say it would be, Windows Terminal is _both_ extremely slow _and_ conhost is extremely slow, each for about a 10x hit that combine for a 100x hit.
1 reply 0 retweets 4 likes -
Thanks for the clarification, I was looking at the code trying to verify that but didn't see any of the conpty APIs being touched. But you mentioned ~22:50 that you should measure how splat looks with VT mode turned on which is what confused me - I don't know what good
1 reply 0 retweets 0 likes -
Replying to @Tyriar @cmuratori and
conpty/conio would do without VT parsing enabled. But anyway to summarize my thoughts: - Yes cache them glyphs - Yes+ make conio faster as it will make the terminal I work on faster
1 reply 0 retweets 0 likes -
Yeah - the goal of this entire exercise was just to demonstrate that Windows Terminal would get 10x faster if they rendered sensibly, and also they'd get another 10x faster on top of that if they fixed conhost etc. There is probably another 10x on top of that for optimization...
2 replies 0 retweets 3 likes
... but I didn't optimize my code so I suspect that the two seconds it currently takes for a 1gb file is just my byte-by-byte parser sucking. So at some point I will do more testing to find out how much more headroom there is, but the 100x I showed is almost certainly still low!
-
-
I agree, someone who works with me on xterm.js focuses hard on throughput so i know there's a lot you can squeeze out there (though we need to deal with JS which has another set of problems).
1 reply 0 retweets 0 likes -
Replying to @Tyriar @cmuratori and
Realistically though the 10x from fastpipe wouldn't be able to be entirely eliminated as I understand it's a fairly complex problem. Additionally it's critical to backwards compatibility of Windows console apps so it has to do things sometimes like rerender the whole screen.
2 replies 0 retweets 0 likes - Show replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.