Refterm v2 - Resource usage, binary splat, glyph sizing, and more
Why Hacker News recommends it
HN points to it as proof that a small, straightforward renderer can beat Windows Terminal on speed and memory, whenever software slowness comes up.
What it is
Casey Muratori follows up his refterm proof-of-concept, a GPU-based terminal renderer, with a second part covering memory usage, glyph sizing and correct Unicode and VT handling. It is built to show that a terminal can be fast and correct without heroic effort.
Recommended by 3 HN commenters across 4 different months, 2021 to 2025.
What Hacker News said
Recommends fredrikholm · 2021-07 · on “Looking at the Performance of Refterm”
In his follow up video[0], he shows that in-use-memory is half that of Windows terminal, whilst simultaneously being >100x faster. Windows terminal chugging away in the background consuming 20% CPU for minutes at a time whilst he's debunking these claims / running the same data on refterm a few times over is hilarious (inflammatory or not). 0. [this video]
Recommends mariusor · 2021-07 · on “Warp: Fast, Rust-based terminal (waiting list)”
You should look into Casey Muratori's quest[1] against Windows terminal slowness on github and youtube. There were some heated exchanges there and some proof of concept software created to demonstrate both how slow Windows Terminal is, and how fast a GPU enabled terminal can be. [1] The latest video for it is here: [this video]
Recommends jiggawatts · 2021-08 · on “WireGuardNT, a high-performance WireGuard implementation for the Windows kernel”
For reference, I've never seen the built-in Windows VPN protocols exceed ~70 Mbps in any scenario. Maybe it's possible with a crossover cable between two Mellanox 100 Gbps NICs, using water-cooled and overclocked CPUs, but not over ordinary networks with ordinary servers. I have gigabit wired Internet to a site with gigabit Internet. Typical performance of SSTP or IKEv2 is 15-30 Mbps. That's 1.5% to 3% max utilisation of the available bandwidth, which is just... sad. It's not the specific site either, other vendor VPNs can easily achieve > 300 Mbps over the same path. It's a year and a half into the pandemic, there are record numbers of people working from home, and Microsoft is the world's
Recommends jiggawatts · 2021-10 · on “It takes a PhD to develop that”
Don't assume. Casey Muratori produced a highly correct Unicode renderer with correct VT code support. Watch the video: [this video]
Recommends jiggawatts · 2022-09 · on “Why modern software is slow”
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 t
Cites siproprio · 2021-08 · on “Windows Terminal Preview 1.11 Release”
It's been slow like this (and with lots of user complaints!) since always! Perhaps you guys should borrow some of those Microsoft research phd folks to improve terminal performance[1]. [1]: [this video]
Cites jiggawatts · 2021-10 · on “It takes a PhD to develop that”
This particular case was discussed at length on Reddit and on YC News. The general consensus was that the Microsoft developers simply didn't have performance in the vocabulary, and couldn't fathom it being a solvable problem despite having a trivial scenario on their hands with no complexity to it at all. The "complaining developer" produced a proof of concept in just two weekends that notably had more features[1] and was more correct than the Windows Terminal! RefTerm 2 vs Windows Terminal in action: [this video] Refterm 2 source: [LINK] One of the previous discussions: [LINK] [1] Features relevant to the debate at any rate, which was that it is possible to write a high-performance terminal rend
Cites dr_zoidberg · 2022-01 · on “Rich: A Python library for rich text and formatting in the terminal”
> 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] [LINK] [1] [this video] [2] [LINK]