refactor(tvix/eval): use im::Vector for NixList representation

This is a persistent, structurally sharing data structure which is
more efficient in some of our use-cases. I have verified the
efficiency improvement using `hyperfine` repeatedly over expressions
on nixpkgs.

Lists are not the most performance-critical structure in Nix (that
would be attribute sets), but we can already see a small (~5-10%)
improvement.

Note that there are a handful of cases where we still go via `Vec`
that need to be fixed, most notable for `builtins.sort` which can not
currently be implemented directly using `im::Vector` because of a
restrictive type bound.

Change-Id: I237cc50cbd7629a046e5a5e4601fbb40355e551d
Reviewed-on: https://cl.tvl.fyi/c/depot/+/7670
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
This commit is contained in:
Vincent Ambo 2022-12-29 14:44:09 +03:00 committed by tazjin
parent 6ab8320f07
commit 5d73c06b1a
8 changed files with 261 additions and 46 deletions

View file

@ -772,7 +772,12 @@ mod pure_builtins {
#[builtin("sort")]
fn builtin_sort(vm: &mut VM, comparator: Value, list: Value) -> Result<Value, ErrorKind> {
let mut list = list.to_list()?.into_vec();
// TODO: the bound on the sort function in
// `im::Vector::sort_by` is `Fn(...)`, which means that we can
// not use the mutable VM inside of its closure, hence the
// dance via `Vec`. I think this is just an unnecessarily
// restrictive bound in `im`, not a functional requirement.
let mut list = list.to_list()?.into_iter().collect::<Vec<_>>();
// Used to let errors "escape" from the sorting closure. If anything
// ends up setting an error, it is returned from this function.