From b6ab02e48bf9e852f495a01d79fc97a1409e0a8b Mon Sep 17 00:00:00 2001 From: sterni Date: Tue, 6 Sep 2022 21:39:03 +0200 Subject: [PATCH] docs(tvix/eval): propose builtin "inlining" optimisation Change-Id: I96a187792a1fd48cffd6b56ec22347aee8cae3af Reviewed-on: https://cl.tvl.fyi/c/depot/+/6526 Autosubmit: sterni Reviewed-by: tazjin Tested-by: BuildkiteCI --- tvix/eval/docs/known-optimisation-potential.md | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/tvix/eval/docs/known-optimisation-potential.md b/tvix/eval/docs/known-optimisation-potential.md index fad773d7d..9390e8c60 100644 --- a/tvix/eval/docs/known-optimisation-potential.md +++ b/tvix/eval/docs/known-optimisation-potential.md @@ -62,6 +62,24 @@ optimisations, but note the most important ones here. The same thing goes for resolving `with builtins;`, which should definitely resolve statically. +* Inline fully applied builtins with equivalent operators [medium] + + Some `builtins` have equivalent operators, e.g. `builtins.add` + corresponds to the `+` operator, `builtins.hasAttr` to the `?` + operator etc. These operators additionally compile to a primitive + VM opcode, so they should be just as cheap (if not cheaper) as + a builtin application. + + In case the compiler encounters a fully applied builtin (i.e. + no currying is occurring) and the `builtins` global is unpoisoned, + it could compile the equivalent operator bytecode instead: For + example, `builtins.add 20 22` would be compiled as `20 + 22`. + This would ensure that equivalent `builtins` can also benefit + from special optimisations we may implement for certain operators + (in the absence of currying). E.g. we could optimise access + to the `builtins` attribute set which a call to + `builtins.getAttr "foo" builtins` should also profit from. + * Avoid nested `VM::run` calls [hard] Currently when encountering Nix-native callables (thunks, closures)