Hacker News new | past | comments | ask | show | jobs | submit login
Lowering resource usage with foot and systemd (rgoswami.me)
69 points by HaoZeke 9 months ago | hide | past | favorite | 30 comments



The title is kinda odd. "Lowering resource usage of foot with systemd" sounds more appropriate.

Not knowing that foot is a terminal emulator, I assumed that foot is some kind of improved resource manager that allows for a general lesser resource usage.


Yes - agreed.


I don't want to switch to Wayland for now, but I will check foot when I do.

I do the same thing with URxvt as a systemd daemon, Tmux as a transient service with systemd-run from .bashrc, and a script in i3wm to run URxvtd client or hide/get the window.

The way I use to run Tmux from a transient service locally and in ssh with the same .bashrc is nice I think. Tmux will survive the terminal and even if I close my session and come back to it:

  #!/usr/bin/env bash
  # ~/.bashrc: sourced by bash(1) for non-login shells.
  
  # If not running interactively, don't do anything
  case $- in
    *i*) ;;
    *) return ;;
  esac
  
  chmod 700 ~/.bashrc.d
  chmod 600 ~/.bashrc ~/.bashrc.d/*
  
  # check if we are already in a Tmux session and not in ssh then open/attach the default one
  if [[ ! "${TERM}" == "tmux"* ]] && [[ -z "${TMUX}" ]] && [[ -z "${SSH_CONNECTION}" ]] && command -v tmux 1> /dev/null; then
    # attach or start the local default Tmux session
    if systemctl --quiet $([[ $(id -u) != 0 ]]; echo "--user") is-active tmux-local-$(id -un).scope; then
      tmux -L local-$(id -un) attach-session -t local-$(id -un) ; exit
    fi
    systemd-run -q --unit tmux-local-$(id -un) --scope $([[ $(id -u) != 0 ]] && echo "--user") tmux -L local-$(id -un) new-session -s local-$(id -un) ; exit
  elif [[ -z "${TMUX}" ]] && [[ -n "${SSH_CONNECTION}" ]] && command -v tmux 1> /dev/null; then
    # attach or start the ssh default Tmux session
    if systemctl --quiet $([[ $(id -u) != 0 ]]; echo "--user") is-active tmux-ssh-$(id -un).scope; then
      tmux -L ssh-$(id -un) attach-session -t ssh-$(id -un) ; exit
    fi
    systemd-run -q --unit tmux-ssh-$(id -un) --scope $([[ $(id -u) != 0 ]] && echo "--user") tmux -L ssh-$(id -un) new-session -s ssh-$(id -un) && exit || echo 'Tmux Systemd unit failed/exited'
  
  fi
  
  # if Tmux is not installed or if we are inside a Tmux session continue the sourcing
  for file in ~/.bashrc.d/*.bashrc;
  do
    source "${file}"
  done


I never heard about it but foot is a terminal emulator with some server mode [1].

1: https://wiki.gentoo.org/wiki/Foot#Server_mode_configuration


Yup, I switched a few years ago from i3 (X11) to sway (Wayland) and use it to replace urxvt.


I had never heard about it either.

Here is the project official repository: https://codeberg.org/dnkl/foot


Thanks! I was wondering about that one as well.


Really enjoyed foot! Runs along the same lines of emacs server and emacsclient.

I ended up dropping it for the same reason I dropped emacs server. There are rare edge cases which causes the server to hang and thus taking down not just one instance of your work, but all of it. Losing the resilience of multiple processes is not worth the RAM it saves, not on modern hardware.


That's a valid point. It might be more about using the right tool for the task. For example, using tmux for persistent terminal windows can help. A setup where the main compilation terminal (subFloat) and smaller terminal instances for chat/irssi/nmpc (mS) run within a tmux session ensures persistence even if foot crashes (or is killed for applying configuration updates) as noted in the post ^_^


I just use it in normal / non server mode. Never had a crash. It’s still low resource and snappy enough for me.


IMO the best part of the foot client/server setup is not lower memory usage, but faster terminal opening time. Starting alacritty is kinda slow. Maybe not a second, but noticeable. Starting foot standalone is definitely faster. Opening a foot window via an already running server is near instant.


> Starting alacritty is kinda slow.

I keep seeing comments like this popping up on HN. Do you guys have some funky esoteric configs?

In my case, where I only changed the color scheme and font, the limiting factor when starting alacritty is how fast I can move my fingers to the i3 shortcut. And I'm not running this on some exotic, fast hardware, just your standard crappy corporate HP laptop from a few years ago.

The only time there was a noticeable lag was when my zsh config was borked.


I think the concept of slow is relative here, for a no configuration start (from a fresh install) alacritty is slower by a factor of 4 https://news.ycombinator.com/item?id=40559084

However the absolute times are still probably not noticable unless you often cold-start terminals.

                     | Alacritty | Foot | Foot Client |
  Absolute time (ms) |    99.0   | 37.2 | 22.8        |


I can say personally that I switched away from alacritty because I would press my key bind and start typing, and it would consistently miss letters because I hadn’t waited for it to fully load. Foot does not.

If it was an app I opened by pressing Super and typing “terminal”, I probably wouldn’t need the speed increase. But the shortcut is easily accessible from home row, so I press it often and quickly.


I switched from konsole to foot, when I upgraded to plasma6 (and therefore to wayland). One of the main reasons was actually startup time. I compared several terminals (konsole, alacritty, kitty, wezterm, foot) and foot had a notably faster startup time than the rest. For me it starts fast enough without a client/server setup, whereas konsole often slightly annoyed me, when I just wanted to execute a single command.


> Right of the bat, it is rather evident that this configuration will spawn two instances of foot, one for each scratchpad.

> Figure 1: Snapshot of memory consumption (from btop), clients take around 10x less memory

By all means use a server/clients approach if it reduces per-process memory, but it's probably not as bad as it looks, because AFAIK the actual executable only gets loaded once and then reused. So each process has its own data in RAM, but the executable/binary only gets loaded the once.

Also, if this is a problem maybe revisit your choice of terminal? It's annoyingly hard to get a total (or more likely I just don't know how to get it), but every number I can seem to find says alacritty is only using <2MB total on my box, so your 27M max on foot looks... weird. Like, I can run a full standalone terminal in the size of your client; I appreciate that it might have features that make it worthwhile, but consider the tradeoffs?


btop might be measuring the wrong thing here, but alacritty on my box shows 93M using the same interface. I remember benchmarking foot and alacritty (also kitty) pretty extensively a few years ago, and settled on foot.

Though of course, the memory usage on modern machines is really not a major issue, but the configuration update, along with the tmux session death was annoying..

EDIT: Some timing metrics..

  foot -s &
  hyperfine --warmup 8 'alacritty -e true' 'foot -e true' 'footclient -e true'
  Benchmark 1: alacritty -e true
    Time (mean ± σ):      99.0 ms ±  14.2 ms    [User: 58.5 ms, System: 33.4 ms]
    Range (min … max):    82.7 ms … 148.3 ms    32 runs

  Benchmark 2: foot -e true
    Time (mean ± σ):      37.2 ms ±   2.3 ms    [User: 40.3 ms, System: 9.5 ms]
    Range (min … max):    33.8 ms …  43.7 ms    83 runs

  Benchmark 3: footclient -e true
    Time (mean ± σ):      22.8 ms ±   4.3 ms    [User: 0.9 ms, System: 0.8 ms]
    Range (min … max):    18.2 ms …  63.6 ms    133 runs

  Summary
    footclient -e true ran
      1.63 ± 0.32 times faster than foot -e true
      4.35 ± 1.03 times faster than alacritty -e true


timing footclient -e true is not actually measuring what you think its measuring. It's measuring the time it takes to open a socket and write a few bytes to it. Not the time it takes to run true in a new window and then close it. And just FYI both alacritty and kitty have server/client modes too. foot without server client mode does indeed startup faster than any GPU based terminal emulator because GPU based terminal emulators have to probe the GPU card(s) ont he system for their capabilities which is approx 100ms of unavoidable delay until someone convinces the kernel developers to cache this data.

In client server mode all of foot/alacritty/kitty/urxvt will open windows in a few ms.


Good point, however, window creation times aside, the official project org has some benchmarks (https://codeberg.org/dnkl/foot/src/branch/master/doc/benchma...) demonstrating speed-ups in most / all user metrics (a more nuanced discussion is on the performance page: https://codeberg.org/dnkl/foot/wiki/Performance)


> it's probably not as bad as it looks, because AFAIK the actual executable only gets loaded once and then reused

The actual foot executable is 427kb. RAM consumption win in the server setup is the shared glyph cache, which is most of the usage at startup.

> alacritty is only using <2MB total on my box

That would be less than the image it’s drawing on screen, the glyph cache, or alacritty’s 11Mb executable. How are you measuring?


> foot is a lightweight terminal emulator designed for Wayland, focusing on minimal resource usage while maintaining performance.

https://codeberg.org/dnkl/foot

For those out of the loop


Still no ligatures support in foot, which is critical in dev environment.


Do you mean "critical" literally or hyperbolically? I disable ligatures in any editor/terminal I use, because I find them confusing and want to know what the actual characters in the code are.


I think there are still dev environments where ligatures in terminals are not so critical. Especially those of devs who do not use in-terminal editors for most of their editing.


I use and love ligatures, but calling them "critical" is weird. I'll have to admit that they're the reason I don't use alacritty, though.


This is why I run xvfb in systemd instead of using something like xvfb-run which spawns a new virtual display every time you run it.


> Since I often work in strong sunlight, I often want to reconfigure my terminal to use a light or a dark scheme depending on the time of day.

Konsole can switch color theme with simple dbus message.

For the rest, I use tmux sessions and some scripts. When I restart computer, all terminal windows with remote ssh sessions get restored.

I do not need any modifications on server (except tmux or screen package).


I thought the "written by human not AI" badge was kind of cute, then I clicked on it. It seems like people pay for the "right" to put that badge on their page? The author was scammed.


OP here, I guess things have changed? AFAIK there was no pricing when I set it up... I just put the image with the link, certainly wouldn't pay for it :D

EDIT: So the payment is to have a little space on their own website, which they call a "project page" e.g. https://notbyai.fyi/hi/not-by-ai/

They suggest "linking to it for verification", but it really seems both unnecessary and optional


I see, thanks for the clarification




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: