[EPILEPSY WARNING] How fast should an unoptimized terminal run?

As luck would have it, here's the continuation to Windows Terminal. Casey Muratori made a reference terminal renderer: [LINK] This uses all the constraints that the Windows terminal team cited as excuses: it uses Windows subsystems etc. One person, 3k lines of code, it runs 100x the speed of Windows terminal. See the epic demo (and stay till the end for color output): [VIDEO]

Worth watching Casey Muratori's series of videos on terminals, and how to implement them, where he often makes specific comparison to Windows Terminal. He has some specific criticisms that are easy to disagree with, but the vast majority are well warranted. His broader series of videos on the topic are even worthwhile from a purely "software engineering education" standpoint. [VIDEO] I feel a bit bad about posting comments about it relatively frequently on HN, but it's just so very very good, and snark aside, his perspective is extremely valuable.

With some limitations that I can’t remember, that I believe were minor and not insurmountable, Casey actually implemented a windows terminal with the “PhD” level work mentioned in this issue. He showcases it here. [VIDEO] I watched it months ago, but from memory, I believe: - it has better Unicode/layout support than windows-terminal - it renders as fast as promised - it has a tiny code base

Link to dev's presentation of their implementation that seems to run circles around microsoft's terminal: [VIDEO]

Oh, this is nothing . Windows force-updated my Notepad.exe to the new modern UI version. It is very visibly laggy for basic actions such as opening menus or scrolling through text. You have to be spectacularly bad at programming to make something so basic so slow in 2022 on a very high-end gaming computer. Not just bad, but utterly oblivious. Casey Muratori excoriated the Windows Terminal dev team for failing to achieve a consistent 60 fps when displaying fixed-width text, which is such a trivial exercise that Casey whipped up a demo in like two weekends. [1] Now the Notepad team insisted on following in the Windows Terminal team's footprints and slowing down the other fixed-width text app that needs to be lightweight fast for all sorts of reasons. Nobody needs Notepad to be pretty. Everyone needs it to work .[2] Just amazing to see something like this happen. It's like a slow motion train wreck, ruining one Windows app at a time. [1] These videos are especially "shocking" because the code he wrote is terse, straightforward, lightning fast, and more correct than whatever madness Microsoft was doing. First weekend: [VIDEO] Second weekend: [LINK] [2] For example, opening a 300 MB log file takes a solid minute of time, which is absurdly slow. It also bloats this to 800 MB of memory usage. For comparison, TextPad opens it in 5 seconds and uses 30 MB of memory. VS Code, an electron application(!) opens in under 2 seconds.

Author here. It is very implausible :) After watching an inspiring video on terminal optimization [1], I started doing some napkin math on how fast my ex-employers' programs "should" run and how many resources they "should" take up. With my very small sample size (N=5), those numbers definitely hold. My big untested assumption is that most startups have even worse codebases than what I've experienced in my short tenure haha. I'd be curious what an "average" startup could achieve in 6 weeks. [1] [VIDEO]

Casey Muratori has some great YouTube videos (a.k.a.: rants) about the end-user visible performance degradation over the last two decades despite computers becoming 10-100x faster by various metrics. E.g.: Visual Studio Rant [LINK] How fast should an unoptimized terminal run? [VIDEO] The root cause is that Microsoft simply doesn't have performance as a priority. It's not a KPI for (almost) anyone, certainly nobody in the desktop teams. Upper management doesn't prioritize input latency over telemetry or advertising "features". It's that simple. There's no pressure, no rejection of slow code, no metrics, no pride in good engineering. If it barely functions, it's good enough to ship.[1] Microsoft employees will occasionally comment to say otherwise, but their statements are contrary to easily verifiable facts, such as massive performance degradations in trivial tools such as the new Notepad, the new Terminal, and the Calculator app. The actual specific technical reasons include: - Executables used to be loaded from disk one 4KB page at a time. Execution could start as soon as the first 4KB block was loaded. For a long time now, executables are digitally signed using a hash like SHA1 or SHA256, which means that large executables can't actually start running any code until the entire file is loaded. The obvious fix -- that didn't occur to anyone at Microsoft -- is to use a Merkle tree hash instead of a linear, single-threaded, whole-file hash like SHA256. - Similarly, anti-malware

It's well known, but this video[1] is a proof of concept demonstration from 4 years ago, Casey Muratori called out Microsoft's new Windows Terminal for slow performance and people argued that it wasn't possible, practical, or maintainable to make a faster terminal and that his claims of "thousands of frames per second" were hyperbolic, and one person said it would be a "PHD level research project". In response, Casey spent <1 week making RefTerm, a skeleton proto-terminal with the same constraints Microsoft people had - using Windows APIs for things, using DirectDraw with GPU rendering, handling terminal escape codes, colours, blinking, custom fonts, missing font character fallback, line wrap, scrollback, Unicode and Right-to-Left Arabic combining characters, etc. RefTerm had 10x faster throughput than Windows Terminal and ran at 6-7000 frames per second. It was single-threaded, not profiled, not tuned, no advanced algorithms, no-cheating by sending some data to /dev/null, all it had to speed it up was simple code without tons of abstractions and a Least Recently Used (LRU) glyph cache to avoid re-rendering common characters, written the first way that he thought of. Around that time he did a video series on that YouTube channel about optimization and arguing that even talking about 'optimization' was too hopeful, we should be talking about 'not-pessimization', that most software is not slow because it has unavoidable complexity and abstractions needed to help maintenance, it