Attukal Bhaskaran

Appreciate the follow-up, and no apology needed for building something. The only issue was the characterization of the comparison. I'm sorry it got so much attention! I gave the feedback in exactly the same tone and style I would if someone I worked with professionally (at any level) came to me and showed me the work and made the same claims. I looked at the way you process/drop data in your circbuffer and VT parser and I was suspicious of HOW much you want to sacrifice correctness, so I want to be specific about what "sacrifices correctness" means here, because I think it's more than it sounds. I'm NOT trying to "mog you" or be mean here, I'm just trying to point out some things you might find helpful, and perhaps help you learn something (if you want). - A 120 KB plain text file: 137 of 300 lines never exist (e.g. your dropping data that technically fits in your scrollback), and the first visible row is a mid-line cut-off fragment. - Same file preceded by CSI ?1049h (the alt-screen switch) is dropped, so all 163 surviving rows land on the primary screen and in scrollback. - A cut inside a truecolor SGR prints `;2;226;54;22m` as text. Similarly, a cut inside an OSC 8 prints the URI as text. The threshold for this isn't a massive firehose. It's any output over 64 KiB between frames: a `git diff`, a stack trace, `ls -R`, a verbose build. That's ordinary terminal use, almost completely ordinary text. A terminal is a stateful protocol, as you hopefully know. If a mode change is in the dropped span (alt screen, bracketed paste, mouse tracking, kitty keyboard flags, a scroll region), the app and the terminal disagree for the rest of the session and nothing resyncs them short of a full RIS. The line-based skipping also can't be made correct even in principle, because terminal state isn't line-local. SGR persists across lines, cursor position depends on every CR/BS/tab/wide char before it, and full-screen apps don't emit newlines at all, they use CUP. I repeat: none of this is shade. "Greedy, drops data, trades correctness for speed" is fine. It's just a different category from a terminal emulator, and I would highly recommend you do not call it that. And again, I hope you understand especially at this point, that I'm giving this feedback in an earnest way attempting to educate and help. I would give the feedback the same way to anyone who works with me. Good luck with your project.

I like to look at claims like this in case I can improve Ghostty. I grabbed your source and immediately spotted the issue: your read loop overwrites a 64 KiB ring. Everything older is discarded unparsed per tick. You're faster because you're not actually terminal emulating. It means the number isn't a throughput number. In a kitten benchmark run at the rate you're claiming, roughly 6.6 MB arrives per 60 Hz tick and 64 KiB of it gets parsed. You're read(2)-ing 100% of the data and parsing about 1% of it. There are other minor issues (a small fixed scrollback in a preallocated ring buffer, no grapheme clustering, throwing away data like OSC 8 URIs, etc.), but the major one is simply that you're discarding ~99% of the input. For plain text, e.g. your cat benchmark, the final screen ends up looking right, but the scrollback is missing 99% of the file and each retained chunk starts mid-line. As soon as there are escape sequences in the dropped spans, your emulator is fully out of sync and invalid: a cut inside a CSI prints the parameters as text, and any SGR, mode, title, or alt-screen change in the gap is just... gone. FYI, this is why I don't like when people point at refterm as a terminal benchmark. refterm implements a TINY subset of what a terminal emulator must support, it's closer to a fast file reader, not a terminal emulator. I also don't mean any shade by this. I like to look at technology objectively to try to learn something and improve my own craft and work. So I'm sharing what I found. I modified your code very slightly to parse on every full buffer (rather than per tick). And the results are attached. Both use main commit in each repo at the time of this post. Note the graph is in log scale, the discrepancy between performance for things like Kitty images is measured in GB/s.