Looking at the Performance of Refterm

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.

Goodness. This feels like the author didn’t watch the video. Not sure there’s much criticism here to even respond to.

I 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.

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 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.

Give the (refterm) author a break!