Live data from Hacker News

Lowering resource usage with foot and systemd

rgoswami.me

1–10 of 33 posts

Re: Lowering resource usage with foot and systemd

#5
> 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 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?

Re: Lowering resource usage with foot and systemd

#6
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.

Re: Lowering resource usage with foot and systemd

#7

> 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 pr…

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

Re: Lowering resource usage with foot and systemd

#8

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 ^_^

Re: Lowering resource usage with foot and systemd

#9
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
Post reply on HN