2
points
HaoZeke
Joined 714 karma
[ my public key: https://keybase.io/haozeke; my proof: https://keybase.io/haozeke/sigs/Y9om1s-BzSlBCd6hmKRtV8EKf-y4M4U-0hiWUNq7YOY ]
Verifying my Blockstack ID is secured with the address 1N99cmSNnQHLbAuxBcCQqnSRNWZgwxgMc8 https://explorer.blockstack.org/address/1N99cmSNnQHLbAuxBcCQqnSRNWZgwxgMc8
[Verifying my OpenPGP key: openpgp4fpr:74b1f67d8e43a94a755407689ccce36402cb49a6]
Avid amateur security and linux enthusiast. Also into molecular simulations and Quantum Computing. More here: https://rgoswami.me
- 1 point
- 2 points
- 2 points
- 3 points
- 2 points
- 1 point
- 1 point
- 4 points
- 1 point
- HaoZeke parentGood 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)
- 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 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://www.hackerneue.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 | - 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 ^_^
- 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 - 69 points
- I should point out that this has been posted [1], but not for the past half decade, long enough to need another PSA :)
[1] https://hn.algolia.com/?q=https%3A%2F%2Fagner.org%2Foptimize...
- 95 points
- 2 points
- 26 points
- 2 points
- 2 points
- 1 point
- 3 points
- 252 points
- 1 point