docs(tvix/TODO): add Correctness > Performance section

Explain the current caveats as far as performance tuning is concerned.

Change-Id: I1a9c11c81de09350240fb61e3c130fc401ef6618
Reviewed-on: https://cl.tvl.fyi/c/depot/+/12141
Autosubmit: flokli <flokli@flokli.de>
Reviewed-by: yuka <yuka@yuka.dev>
Tested-by: BuildkiteCI
This commit is contained in:
Florian Klink 2024-08-07 13:12:42 +03:00 committed by clbot
parent f9703a9af5
commit c2c4169e49

View file

@ -39,7 +39,37 @@ sure noone is working on this, or has some specific design in mind already.
the checks we currently have when converting from `Vec<u8>` to `B3Digest` in
various places.
## Perf
### Correctness > Performance
A lot of the Nix behaviour isn't well documented out, and before going too deep
into performance optimizations, we need to ensure we properly grasped all hidden
features. This is to avoid doing a lot of "overall architecture perf-related
work" and increased code complexity based on a mental model that might get
disproved later on, as we work towards correctness.
We do this by evaluating more and more parts of the official Nix test suite, as
well as our own Tvix test suite, and compare it with Nix' output.
Additionally, we evaluate attributes from nixpkgs, compare calculated output
paths (to determine equivalence of evaluated A-Terms) and fix differences as we
encounter them.
This currently is a very manual and time-consuming process, both in terms of
setup, as well as spotting the source of the differences (and "compensating" for
the resulting diff noise on resulting mismtaches).
- We could use some better tooling that periodically evaluates nixpkgs, and
compares the output paths with the ones produced by Nix
- We could use some better tooling that can spot the (real) differences between
two (graphs of) derivations, while removing all resulting noise from the diff
in resulting store paths.
### Performance
Even while keeping in mind some of the above caveats, there's some obvious
low-langing fruits that could have a good impact on performance, with somewhat
limited risk of becoming obsolete in case of behaviorial changes due to
correctness:
- String Contexts currently do a lot of indirections (edef)
(NixString -> NixStringInner -> HashSet[element] -> NixContextElement -> String -> data)
to get to the actual data. We should improve this. There's various ideas, one