Hacker News Reader

Comment by Kukumber | Hacker News Reader

145mb-226mb for a terminal

that's worse than an electron terminal

something is wrong

Looks like the macOS binary size is a combination of shipping 3 binaries, each with most of the application compiled in (and statically linked), and containing builds for both Apple Silicon and x86 in each.

  2 % tree .
  .
  └── Contents
   ├── Info.plist
   ├── MacOS
   │   ├── strip-ansi-escapes
   │   ├── wezterm
   │   ├── wezterm-gui
   │   └── wezterm-mux-server
   ├── Resources
   │   ├── terminal.icns
   │   └── wezterm.sh
   └── _CodeSignature
    └── CodeResources

  2 % du -hs Contents/MacOS/*
  2.8M    Contents/MacOS/strip-ansi-escapes
   48M    Contents/MacOS/wezterm
  119M    Contents/MacOS/wezterm-gui
   44M    Contents/MacOS/wezterm-mux-server

A bit of duplicative bloat, but there's nothing wrong with that for an young project trading a bit of space for an easier build/release process.

Keep in mind, wezterm is a statically linked binary, while builtin and distro-provided packages will use dynamic linking. Depending on how it's built, it may also have embedded debuginfo and lack LTO.

It is a bit frustrating how much hate Electron gets but statically compiled languages are all the rage & general concensus is it's totally sweet.

It is not just about size of the app but also RAM footprint.

Rust has the NodeJS/Python dependency tree bloat problem.

Unlike other terminal emulators, this project is entirely statically compiled, so the code for the built-in SSH client, serial port support, muxing server/client protocol, shader compilation engines, image decoding libraries, D-BUS clients, threading libraries, HTTP(S) (1.1/2/3) with several types of compression, and of course the GPU shader compilers and APIs.

I built Wezterm on my machine and the binary is about 21MiB in size. About 12MB of that is code, the rest is debug symbols. 2MB of that is the Rust standard library and another 1MB is a LUA runtime. Then there are several image libraries that take about half a megabyte.

The compiled source code itself is only 893KiB in my file. The rest is just dependencies and random ELF segments.

So yes, the terminal emulator is about one Windows 95 installation in size, but that's all quite explainable if you care about the features.

For comparison, I've run `debtree` on gnome-terminal (3.4KiB on disk) and the dependency tree is reported to be 691MiB. Microsoft's Windows Terminal is distributed in 18.6MiB - 66.4MiB (I don't know the compression msixbundles use if any) which is comparable. iTerm2 seems to be about 74MiB decompressed. Even `xterm` (the most barebones terminal emulator I can find) relies on 20MiB of dependencies.

If xterm is all you need, then there's no need to download anything else. If you want more features in a terminal emulator, you're going to have to deal with larger binaries.

It's easy to downvote, but the question is not totally out of place.

On my machine:

* WezTerm 224 MB

* iTerm2 74 MB

* Terminal (default MacOS) 10 MB

And yet, I have read comments proclaiming that iTerm is bloatware.

p.s. I've been using Wezterm for more than a year, and I love it.

terminal.app doesn't even support true color (for starters)... apples and oranges.

Terminal.app is (was?) very good on the latency side though: https://danluu.com/term-latency/

Yeah it's a shame they aren't updating it because the typing experience is one of the best.

This is the size of the binary or RAM usage? If the size the binary, does it matter in most cases? If the size of RAM, yeah, I can see how that seems a lot for a terminal.

The binary is statically linked and embeds several fonts for a consistent, cross-platform, out of the box experience.

The on-disk size != RAM usage, and on-disk size really doesn't matter on modern systems, unless you're on a very resource constrained system, in which case, you probably don't want a feature-heavy GUI anyway.

Wezterm runs in about 134MiB of RAM on my machine. It's pretty consistent above the baseline, growing to 190MiB with 150 tabs open.

well if you're so sure, look at the code and the feature list[0] (to see what it actually does) then tell us what it is doing wrong.

[0]: https://wezfurlong.org/wezterm/features.html

idk, I am with you and I don't typically care about sizes like this, but this does feel like quite a lot, although not as much as reported above. The split between the two rust programs here is pretty interesting.

[nix-shell:~]$ du -hs $(nix-build '<nixpkgs>' -A wezterm)

94M /nix/store/w7hpqwqqp7xq70wjsm8bd1yara0rhk9v-wezterm-20220408-101518-b908e2dd

[nix-shell:~]$ du -hs $(nix-build '<nixpkgs>' -A kitty)

25M /nix/store/9k0jn3219l6l7ywcqyvbifhd38cagfd9-kitty-0.25.2

[nix-shell:~]$ du -hs $(nix-build '<nixpkgs>' -A alacritty)

6.2M /nix/store/cq7zaagwcwn9blynw027bqszhnld2sk2-alacritty-0.10.1

Is the feature set difference between these really that much? At least, between kitty and wezterm?

Alacritty is basically as minimal a terminal emulator as you're going to get, wezterm is the polar opposite end of the spectrum. Kitty is in the middle, the main thing that wezterm has that kitty doesn't that I'm aware of is the daemon process that allows you to disconnect/reconnect to sessions which is what allows wezterm to function as a tmux replacement (vs kitty can't replace that aspect of tmux). Compared to alacritty, it has multiplexing, ssh sessions (new tabs/panes opened in that session are opened in the context of the remote host without requiring additional authentication), incredibly flexible configuration via lua, etc. And as far as size goes, kitty and wezterm are written in different languages so comparing them directly is not so simple.

If I compare this feature list to e.g. features of xterm (VT52/VT100/VT220/VT320/VT420/partial VT520 support, graphics via Sixel/ReGIS/Tek4014, …), I don't see a single reason why wezterm should be roughly 100MB large (according to pacman on Archlinux) vs roughly 1MB for xterm.

If you think "but terminal multiplexing and SSH!", then feel free to add 0.9MB for screen (or 1MB for tmux) and 4.8MB for openssh, and you're still way below the size of wezterm.

This does seem crazy. I have a hobby project that's a statically linked animation editor (so it does a lot of stuff including exporting/encoding GPU streams into a video). It has AV1, Freetype, and a few other large deps included and it only clocks in at 16.7mb

Reply on news.ycombinator.com