docs(tvix/eval): propose builtin "inlining" optimisation r/4821

Change-Id: I96a187792a1fd48cffd6b56ec22347aee8cae3af
Reviewed-on: https://cl.tvl.fyi/c/depot/+/6526
Autosubmit: sterni <sternenseemann@systemli.org>
Reviewed-by: tazjin <tazjin@tvl.su>
Tested-by: BuildkiteCI

1 files changed, 18 insertions, 0 deletions

diff --git a/tvix/eval/docs/known-optimisation-potential.md b/tvix/eval/docs/known-optimisation-potential.md
index fad773d7da63..9390e8c601fa 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)