20 Hacker News comments link this video. Each one links back to its thread.
dundariousMay 2022Strongly recommends
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. ▶ this 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.
in “Windows Terminal Source Code” · View on HN
dmitriidJul 2021Strongly recommends
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): ▶ this video
in “Apple and Intel first to use TSMC 3nm” · View on HN
jodrellblankJul 2025Recommends
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
in “Fast” · View on HN
jiggawattsMay 2024Recommends
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? ▶ this 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
in “Ask HN: What makes Windows 11 perform much worse than Windows XP?” · View on HN
surprisetalkNov 2023Recommends
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] ▶ this video
in “Compressing Codebase Collocates” · View on HN
jiggawattsSep 2022Recommends
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: ▶ this 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.
in “Why modern software is slow” · View on HN
Show 14 more comments
djoldmanMay 2022Recommends
Link to dev's presentation of their implementation that seems to run circles around microsoft's terminal: ▶ this video
in “When I tell the Windows Terminal team something is simple, I am "misguided"” · View on HN
dundariousOct 2021Recommends
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. ▶ this 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
in “Microsoft: Extremely slow performance when processing virtual terminal sequences” · View on HN
kaelwdNov 2025Cites it
The author of that issue has a whole video series about it: ▶ this video A way faster terminal emulator demo: [link] And a terminal rendering benchmark tool: [link]
in “Drawing Text Isn't Simple: Benchmarking Console vs. Graphical Rendering” · View on HN
zonovarNov 2025Cites it
Not really on 'latency' per se as discussed in the articole but an interesting take on slow terminals is Casey Muratori's famous rant on the topic [0] that led him to write his own terminal [1], a reference renderer for monospace terminal displays that is several orders of magnitude faster than Windows Terminal despite being largely unoptimized. [0] ▶ this video [1] [link]
in “Terminal Latency on Windows (2024)” · View on HN
sllabresMar 2023Cites it
Probably inspired by the performance problems with the windows terminal [1] and the accelerated terminal [2] developed by Molly Rocket as 'answer'? A series of videos presenting the poc [3] [1] [link] (It takes a PhD to develop that) [2] [link] [3] ▶ this video , [link]
in “WezTerm is a GPU-accelerated cross-platform terminal emulator written in Rust” · View on HN
norman784Feb 2023Cites it
You can achieve good memory footprints with Linux, just 2 or 3 years ago I was daily driving Arch linux with bspwm as a window manager, it used only 300 mb, for me is pretty darn good, but as soon as I opened my vscode with a JS project my ram usage was at 12gb. We have a lot of bloatware everywhere, that’s pretty sad. edit: This remind me a some rants from Casey Muratori about VS[0] and windows terminal[1] [0] [link] [1] ▶ this video
in “De-Bloated Windows 11 Build Runs on 2GB of RAM” · View on HN
A4ET8a8uTh0Dec 2022Cites it
Yes and no. I am now running an equivalent of a computer power that was once reserved for some dedicated government agency in early 90s[1]. I accept that some of that power is put to good use, but I do see wasted power in OS [2] and even games [3] on a semi-regular basis. For the record, "they don't make em' like they used to" is an absolutely valid complaint. Note that now even with SSD, ridiculous memory and cpu, websites still manage to stutter ( but I accept online is its own animal ). Part of me wants to go over Windows releases as an example of resource use across generations ( and how they leaped ). <<I distinctly remember experiencing major performance gains when moving to more memory than my system and apps needed to use and the move to solid state drives. But do you still see it or is that performance assumed now ( making lazy design decisions easier )? [1] [link] [2] ▶ this video [3] [link]
in “Driving Amazon’s electric delivery vehicle: Rivian EDV [video]” · View on HN
julianzOct 2022Cites it
Pretty sure this is a Casey Muratori reference. Doesn't really apply to the current project as it's a UI on top of the existing terminal rather than a whole new terminal. More details: ▶ this video
in “Terminal.Gui: A Cross Platform Terminal UI Toolkit for .NET” · View on HN
prometheus76Sep 2022Cites it
Replying to my own comment to add the proof that instead of double-digit fps terminal text rendering, he was able to achieve 4-digit fps terminal text rendering after a weekend of coding: Part 1 (Proof of concept): ▶ this video Part 2 (more features added): [link]
in “Available today: The Windows 11 2022 Update” · View on HN
buchooJun 2022Cites it
Parkinson's law in software is real. As Jon Blow often says, our computers are basically supercomputers that are astoundingly bogged down by bad software development practices. The computer I'm on is at the very least several dozen times more powerful than the one I had 20 years ago, yet a lot of functionally equivalent software probably runs at about the same speed, certainly not an order of magnitude faster let alone several dozen times faster despite not doing several times more. The problem is that a lot of software developers don't even realize how bad their software design is because of prevailing norms, and the state of affairs can only be upended by certain developers showing that another way is possible when programming with the hardware rather than against it. As someone who has to use Visual Studio and ReSharper professionally, I was absolutely blown away when I tried out the (still in alpha) 10x Editor and found it accomplishing in less than a second something that takes ReSharper several dozen seconds, during which it locks up the editor, or that it might even fail to do entirely, having succeeded only in making VS unresponsive (finding all usages of a widely overridden virtual function): [link] (Disclaimer: I was impressed enough by the editor's performance to become a paid supporter.) (Another VS extension I use is P4VS, which is slow, buggy garbage that will lock up VS if you look at it funny. In fact, P4V and the P4 extension for Windows Explorer are also utt
in “Software Disenchantment (2018)” · View on HN
starburstMay 2022Cites it
Sure but in this case it was grossly over-estimated compared to the under-estimated side. Casey did the implementation [1] to prove the point and also made explanatory videos [2] of it. [1] [link] [2] ▶ this video
in “When I tell the Windows Terminal team something is simple, I am "misguided"” · View on HN
cmaFeb 2022Cites it
It is very slow and does more draw calls than a modern video game, melting laptop batteries: ▶ this video Same guy from this video did a series of videos rewriting the renderer in a weekend or so and going hundreds or thousands of times faster, with more advanced unicode/ligature/language support.
in “React Native for Windows is helping Settings improve more quickly” · View on HN
dr_zoidbergJan 2022Cites it
> Layers and layers of cruft which you can trace back to before the computing era. Even those layers and layers don't _have to_ slow things down. Check the refterm "debacle" ([2] for the context, [0, 1] as Muratori's answer to it). It's just the way things are usually programmed doesn't care about performance and how fast things really can be. I sometimes wonder in we're not due for a massive round of optimization on a couple of the layers that we're used to using/depend on. [0] ▶ this video [1] [link] [2] [link]
in “Rich: A Python library for rich text and formatting in the terminal” · View on HN
jiggawattsFeb 2026Joke
> in some terminal emulators, rendering is extremely slow. Ooo... ooo! I know what this is a reference to! ▶ this video
in “Claude Code Is Being Dumbed Down” · View on HN