RE: https://hachyderm.io/@mitchellh/117096017608717427

A couple more notes on this:

First, the xterm.js benchmarks were very noisy. A lot of the results relied on whether they got lucky with the V8 JIT/inliner. e.g. the frame times for ASCII ranged from 20us to 100us (!!!). For the purpose of optimism, I only used the fastest times in the medians below and threw out anything about a 20% deviation from the min.

Ghostty on the other hand had a variation of at most 1.5% on any given run. I suspect this is due to the heavy (near-exclusive) use of WebAssembly, which isn't as beholden to the runtime gods.

Next, bundle size. Ghostty's Wasm bundle is significantly larger than xterm.js. Our fast bundle is ~1.1MB uncompressed. xterm.js ~270KB uncompressed. Both very cache-able. I've tried to optimize this but there isn't a lot of juice to squeeze that I can find, Ghostty has to ship with a huge amount of Unicode tables for example.

@mitchellh is it practical to do smaller builds that don’t include the full Unicode tables and either download on demand or simply not support the full range, which I suspect would be fine in the vast majority of cases?

@jon When I say "destroys IO performance", I don't have the exact numbers in front of me anymore, but it dips to slower than xterm.js. :)

@mitchellh compute the Unicode tables one time in js-land and upload to wasm?

@psnszsn Theres 2^21 codepoints to compute from codepoint-first. I'm not even sure if JS gives us the data we need to be honest (xterm.js does not do proper terminal-accurate multi-codepoint grapheme processing for example). I have to look.