[yjftsjthsd-h]

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

[HaoZeke]

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

[aumerle]

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.

[HaoZeke]

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)

[akho]

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