410d79b151
A whole bunch of optimizations in hot paths in the IO processing areas of our code (well, one of them covers everything). I validated that each commit either improved one or more of our vtebench results, or improved the time it takes to process 2 years worth (2.4GB) of data from asciinema. ## vtebench <img width="1278" height="903" alt="image" src="https://github.com/user-attachments/assets/bad46777-4606-4870-b7d7-8df0c4bb3b39" /> (I decided to patch vtebench to report in nanoseconds instead of milliseconds since clearly it was not designed for a machine as fast as mine. Nanoseconds gives much more useful results when the numbers are this low.) Do note the *slight* regression in the "unicode" test, this is probably because I added a branch hint in `Terminal.print` in order to optimize for printing narrow characters, since they make up the vast majority of characters typically printed in the terminal, but the vtebench "unicode" test is pretty much all wide characters. This shouldn't have a negative effect on users of CJK languages since it's a *very* slight reduction in speed and they will still be printing many narrow characters, especially in TUIs; spaces, box drawing characters, symbols, punctuation, etc. ## asciinema processing I wrote a program that uses libghostty to push 2 years worth (2.4GB) of data from publicly uploaded asciinema recordings in to the terminal as fast as possible- since it's just libghostty, there's no renderer overhead happening, it's just the core terminal emulation, effectively everything that io-reader thread does if it didn't have wait for the renderer ever. On main, this took roughly 26.1–26.7 seconds to process, on this branch it takes just 18.4–18.6 seconds, that's a ~30% improvement in raw IO processing speed when processing real world data! ## Summary of changes In order of commits: - Fixed a bug that I hit when trying to have Ghostty process all that asciinema data, in certain bad cases it was possible to accidentally insert the `0` hyperlink ID in to a page, which would then cause a lockup in ReleaseFast mode when trying to clone that page since the string alloc would try to iterate `1..0` to allocate 0 chunks. - I noticed in profiling Ghostty that `std.debug.assert` was showing up in the profile, which it should not have been since its doc comment promises that it will be optimized out in ReleaseFast- but evidently something is wrong with Zig, or that comment's promise is based on an expectation from LLVM that it fails to meet - but either way, by replacing all uses of `assert` with a version that is explicitly marked `inline`, that function call overhead in tight loops and hotpaths is avoided. This change alone accounts for like a third of the IO processing time improvement, though it had minimal impact on vtebench scores. - I optimized the SGR parser somewhat by adding branch hints and removing the `.reset_underline` action, replacing it with `.{ .underline = .none }`. - Gated a somewhat expensive assert in RefCountedSet behind a runtime safety check. - Improved the performance of `Style.eql` and `Style.hash` since these are hot functions, called extremely frequently since adding styles to the style set is a very common operation. Achieved this by making `eql` less generic - explicitly comparing each part of the style rather than looping over fields - and ordering checks from most likely to differ to least likely to differ so that differences can be found as soon as possible; and changed the hash from xxhash to simply folding the packed struct down to 64 bits and then using `std.hash.int`. Also manually inlined the code from `std.meta.activeTag` in `Packed.fromStyle`, since profiling showed it in the callstack and it's a single cast so it really should not have the function call overhead. - Explicitly marked some trivial functions as inline, the optimizer would already have been doing this (probably) but doing it explicitly gives the optimizer more time to spend on other things. Added cold branch hints to "should be impossible" and error-returning paths that should be very rare, and unlikely branch hints to a lot of "invalid" paths- to optimize for receiving valid data. - Removed a branch in the parser csi param action, just unconditionally multiply by 10 before adding digit value, even if it's the first digit. This codepath is rarely hit since we have a fast path for this in the stream code, but the stream code already has this optimization so I just copied it over. - `CharsetState.charsets` used to be an `EnumArray`, but the layout/access logic for that was less-than-ideal, and the access functions were not inlining-- and these are very hot since we access this for every single print, so I wrote a bespoke struct to hold that info instead, gained a couple percent of IO perf with that. - Added branch hints based on the data I derived from the asciinema dump, which gave big boost to vtebench results, especially for the cursor movement and dense cells tests (which makes sense, since cursor movement and setting attributes both got `likely` hints :p) -- data at https://github.com/qwerasd205/asciinema-stats - This is probably the most invasive change in this PR: I removed the dirty bitset from `Page` and replaced it with a dirty flag on each row, for the majority of operations this is faster to write, since the row being dirtied is probably already loaded and probably will be written to for other changes as well. This gave a couple percent IO processing improvement. The only exception is scrolling-type operations, which are extremely efficient by just moving rows around with a single memmov, so looping through the rows to mark each dirty slows them down, and indeed after this change the scrolling benchmarks in vtebench regressed, *however*... - Added a "full page dirty" flag on `Page`, which is set when an operation is performed that dirties most or all the rows in the page, which is used for scrolling-type operations. This *does* make the dirty tracking slightly less precise for these operations, but with the caching and stuff we do in the renderer, I don't think `rebuildCells` is a bottleneck, so rebuilding a few extra rows shouldn't hurt. After this change, all the scrolling benchmarks in vtebench improved drastically. - Tiny micro-improvements to RefCountedSet; streamlined the control flow in `lookup`, added an unlikely branch hint in `insert` for the branch that resurrects dead items since dead items aren't that common. - Improve SGR parser performance again by using `@call(.always_inline` to explicitly inline calls to `StaticBitSet.isSet` (for the separator list), since I noticed they weren't being inlined, causing function call overhead in a hotpath. - I noticed that `clearGrapheme` and `clearHyperlink` would check every cell in the row after they were done in order to update the `grapheme`/`hyperlink` flag on the row if there were none left, which isn't great since `clearCells` called these functions for multiple cells in the same row back-to-back, which leads to a ton of excess work. I separated the flag updating parts of these functions out and called them only if necessary (if the cells being cleared were the full row then the flag could unconditionally be set to false) and only after all the cells were cleared. This gave a nice improvement to IO processing since clearCells is evidently a very hot function. - Removed inline annotations on `Page.clearGrapheme` and `Page.clearHyperlink` in favor of inlining directly at the one callsite that benefited from inlining, this improved IO processing speed. - Inlined trivial function `Charset.table`. - Inlined `size.getOffset` and `size.intFromBase` as they are both trivial pointer math that often benefits from surrounding context. --- If you'd like me to separate out the trivial improvements (branch hints, inline annotations, 1-line changes) from the functionality-changing ones (pretty much just the changes to dirty tracking), just let me know!
Ghostty
Fast, native, feature-rich terminal emulator pushing modern features.
About
·
Download
·
Documentation
·
Contributing
·
Developing
About
Ghostty is a terminal emulator that differentiates itself by being fast, feature-rich, and native. While there are many excellent terminal emulators available, they all force you to choose between speed, features, or native UIs. Ghostty provides all three.
In all categories, I am not trying to claim that Ghostty is the best (i.e. the fastest, most feature-rich, or most native). But Ghostty is competitive in all three categories and Ghostty doesn't make you choose between them.
Ghostty also intends to push the boundaries of what is possible with a terminal emulator by exposing modern, opt-in features that enable CLI tool developers to build more feature rich, interactive applications.
While aiming for this ambitious goal, our first step is to make Ghostty one of the best fully standards compliant terminal emulator, remaining compatible with all existing shells and software while supporting all of the latest terminal innovations in the ecosystem. You can use Ghostty as a drop-in replacement for your existing terminal emulator.
For more details, see About Ghostty.
Download
See the download page on the Ghostty website.
Documentation
See the documentation on the Ghostty website.
Contributing and Developing
If you have any ideas, issues, etc. regarding Ghostty, or would like to contribute to Ghostty through pull requests, please check out our "Contributing to Ghostty" document. Those who would like to get involved with Ghostty's development as well should also read the "Developing Ghostty" document for more technical details.
Roadmap and Status
The high-level ambitious plan for the project, in order:
| # | Step | Status |
|---|---|---|
| 1 | Standards-compliant terminal emulation | ✅ |
| 2 | Competitive performance | ✅ |
| 3 | Basic customizability -- fonts, bg colors, etc. | ✅ |
| 4 | Richer windowing features -- multi-window, tabbing, panes | ✅ |
| 5 | Native Platform Experiences (i.e. Mac Preference Panel) | ⚠️ |
| 6 | Cross-platform libghostty for Embeddable Terminals |
⚠️ |
| 7 | Windows Terminals (including PowerShell, Cmd, WSL) | ❌ |
| N | Fancy features (to be expanded upon later) | ❌ |
Additional details for each step in the big roadmap below:
Standards-Compliant Terminal Emulation
Ghostty implements enough control sequences to be used by hundreds of testers daily for over the past year. Further, we've done a comprehensive xterm audit comparing Ghostty's behavior to xterm and building a set of conformance test cases.
We believe Ghostty is one of the most compliant terminal emulators available.
Terminal behavior is partially a de jure standard (i.e. ECMA-48) but mostly a de facto standard as defined by popular terminal emulators worldwide. Ghostty takes the approach that our behavior is defined by (1) standards, if available, (2) xterm, if the feature exists, (3) other popular terminals, in that order. This defines what the Ghostty project views as a "standard."
Competitive Performance
We need better benchmarks to continuously verify this, but Ghostty is generally in the same performance category as the other highest performing terminal emulators.
For rendering, we have a multi-renderer architecture that uses OpenGL on Linux and Metal on macOS. As far as I'm aware, we're the only terminal emulator other than iTerm that uses Metal directly. And we're the only terminal emulator that has a Metal renderer that supports ligatures (iTerm uses a CPU renderer if ligatures are enabled). We can maintain around 60fps under heavy load and much more generally -- though the terminal is usually rendering much lower due to little screen changes.
For IO, we have a dedicated IO thread that maintains very little jitter
under heavy IO load (i.e. cat <big file>.txt). On benchmarks for IO,
we're usually within a small margin of other fast terminal emulators.
For example, reading a dump of plain text is 4x faster compared to iTerm and
Kitty, and 2x faster than Terminal.app. Alacritty is very fast but we're still
around the same speed (give or take) and our app experience is much more
feature rich.
Note
Despite being very fast, there is a lot of room for improvement here.
Richer Windowing Features
The Mac and Linux (build with GTK) apps support multi-window, tabbing, and splits.
Native Platform Experiences
Ghostty is a cross-platform terminal emulator but we don't aim for a least-common-denominator experience. There is a large, shared core written in Zig but we do a lot of platform-native things:
- The macOS app is a true SwiftUI-based application with all the things you would expect such as real windowing, menu bars, a settings GUI, etc.
- macOS uses a true Metal renderer with CoreText for font discovery.
- The Linux app is built with GTK.
There are more improvements to be made. The macOS settings window is still a work-in-progress. Similar improvements will follow with Linux.
Cross-platform libghostty for Embeddable Terminals
In addition to being a standalone terminal emulator, Ghostty is a
C-compatible library for embedding a fast, feature-rich terminal emulator
in any 3rd party project. This library is called libghostty.
Due to the scope of this project, we're breaking libghostty down into
separate actually libraries, starting with libghostty-vt. The goal of
this project is to focus on parsing terminal sequences and maintaining
terminal state. This is covered in more detail in this
blog post.
libghostty-vt is already available and usable today for Zig and C and
is compatible for macOS, Linux, Windows, and WebAssembly. At the time of
writing this, the API isn't stable yet and we haven't tagged an official
release, but the core logic is well proven (since Ghostty uses it) and
we're working hard on it now.
The ultimate goal is not hypothetical! The macOS app is a libghostty consumer.
The macOS app is a native Swift app developed in Xcode and main() is
within Swift. The Swift app links to libghostty and uses the C API to
render terminals.
Crash Reports
Ghostty has a built-in crash reporter that will generate and save crash
reports to disk. The crash reports are saved to the $XDG_STATE_HOME/ghostty/crash
directory. If $XDG_STATE_HOME is not set, the default is ~/.local/state.
Crash reports are not automatically sent anywhere off your machine.
Crash reports are only generated the next time Ghostty is started after a crash. If Ghostty crashes and you want to generate a crash report, you must restart Ghostty at least once. You should see a message in the log that a crash report was generated.
Note
Use the
ghostty +crash-reportCLI command to get a list of available crash reports. A future version of Ghostty will make the contents of the crash reports more easily viewable through the CLI and GUI.
Crash reports end in the .ghosttycrash extension. The crash reports are in
Sentry envelope format. You can
upload these to your own Sentry account to view their contents, but the format
is also publicly documented so any other available tools can also be used.
The ghostty +crash-report CLI command can be used to list any crash reports.
A future version of Ghostty will show you the contents of the crash report
directly in the terminal.
To send the crash report to the Ghostty project, you can use the following CLI command using the Sentry CLI:
SENTRY_DSN=https://e914ee84fd895c4fe324afa3e53dac76@o4507352570920960.ingest.us.sentry.io/4507850923638784 sentry-cli send-envelope --raw <path to ghostty crash>
Warning
The crash report can contain sensitive information. The report doesn't purposely contain sensitive information, but it does contain the full stack memory of each thread at the time of the crash. This information is used to rebuild the stack trace but can also contain sensitive data depending on when the crash occurred.