atuin
atuin copied to clipboard
atuinsh
Compile times
I chopped up atuin a little bit and compiled it in 3 different modes
- atuin-full (cli client + sync client + sync server)
- atuin-sync (cli client + sync client)
- atuin-cli (cli client)
(All were compiled in release mode on an M1 with the default linker)
| mode | total | time spent compiling atuin(bin) | idle waiting for libsodium | total deps |
|---|---|---|---|---|
| atuin-full | 3m30s | 84.4s | 15s | 457 |
| atuin-sync | 2m45s | 54.3s | 25s | 426 |
| atuin-cli | 1m30s | 32.4s | 0s | 387 |
Benchmarks run with lto disabled
| mode | total | time spent compiling atuin(bin) | idle waiting for libsodium |
|---|---|---|---|
| atuin-full | 2m25s | 8.1s | 8s |
| atuin-sync | 2m05s | 8.5s | 27s |
| atuin-cli | 1m17s | 3.8s | 0s |
We enabled LTO over a year ago #101 but it's not been shown if it actually provides much performance boost for us. It's worth benchmarking our normal flow (interactive search) to see if it really makes a difference.
As we grow, I think we need to be conscious of compile times. Onboarding new people/getting them to upgrade is going to be hard otherwise if they have a 3+ minute build time.
The atuin-sync mode could be the default going forward. Most users won't be running their own servers.
I've heard from sources that on Linux the libsodium build is a non issue
LTO is not just about increasing the performance, but also decreasing the binary size. It’s typically enabled for release builds only. You can also left it disabled in the release profile and add a new profile with LTO enabled, so the users can decide which one to use (and you can use it for building release binaries on CI).
