Author selects a different success benchmark, gets different results.
Casey's demonstration is specific to the claim that terminal text rendering, by itself, is "worthy of a PhD thesis", as written by a Microsoft employee. He makes no claim to Refterm being an actual terminal emulator, and he repeatedly says that it is not optimized, by which he means that he has never profiled it; it reuses Windows library code, implements a simple LRU glyph cache, and has an option to bypass conio and present a buffer passed directly through the kernel. The code is otherwise just a first pass at achieving the desired features, but it succeeds in demonstrating that a high-bandwidth terminal emulator is possible if pursued with any effort.
In other words, unoptimised code written in a week-end to refute a claim that creating it would be ever so difficult wastes some resources according to some benchmark.
At work, we have code that runs in the browser to fuzzy search a list of database tables. It was slow. I rewrote it to use tries as an index, and it performs two orders of magnitude faster. It also uses two orders of magnitude more memory, and returns unusual results in rare pathological cases.
"Faster" doesn't need to mean "faster by every measure", it needs to mean that it's faster in the ways that matter given the constraints of the problem and what the program is trying to accomplish. The author of the code seems to have been very clear that this was a proof of concept around perceived performance of a specific aspect of the application, and I can't think of how the really doesn't satisfy that.
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).
5 comments
[ 2.7 ms ] story [ 24.1 ms ] threadI watched Casey’s presentation and I think his prototype does an excellent job of dispelling some standard excuses for why this stuff isn’t faster.
Casey's demonstration is specific to the claim that terminal text rendering, by itself, is "worthy of a PhD thesis", as written by a Microsoft employee. He makes no claim to Refterm being an actual terminal emulator, and he repeatedly says that it is not optimized, by which he means that he has never profiled it; it reuses Windows library code, implements a simple LRU glyph cache, and has an option to bypass conio and present a buffer passed directly through the kernel. The code is otherwise just a first pass at achieving the desired features, but it succeeds in demonstrating that a high-bandwidth terminal emulator is possible if pursued with any effort.
Give the (refterm) author a break!
"Faster" doesn't need to mean "faster by every measure", it needs to mean that it's faster in the ways that matter given the constraints of the problem and what the program is trying to accomplish. The author of the code seems to have been very clear that this was a proof of concept around perceived performance of a specific aspect of the application, and I can't think of how the really doesn't satisfy that.
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. https://www.youtube.com/watch?v=99dKzubvpKE