From 71b40ba34ee6de419a6203129d199768b2294235 Mon Sep 17 00:00:00 2001 From: Arseny Kapoulkine Date: Fri, 12 Jun 2020 02:40:28 -0700 Subject: [PATCH] docs: Cleanup compiler wording --- docs/performance.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/docs/performance.md b/docs/performance.md index 77a2f992..037f23bf 100644 --- a/docs/performance.md +++ b/docs/performance.md @@ -21,7 +21,9 @@ Of course the interpreter isn't typical C code - it uses many tricks to achieve ## Optimizing compiler -Unlike Lua and LuaJIT, Luau uses a more classical compiler construction with a frontend that parses source into an AST and a backend that generates bytecode from it. This carries a small penalty in terms of compilation time, but results in more flexible code and, crucially, makes it easier to optimize the generated bytecode. +Unlike Lua and LuaJIT, Luau uses a multi-pass compiler with a frontend that parses source into an AST and a backend that generates bytecode from it. This carries a small penalty in terms of compilation time, but results in more flexible code and, crucially, makes it easier to optimize the generated bytecode. + +> Note: Compilation throughput isn't the main focus in Luau, but our compiler is reasonably fast; with all currently implemented optimizations enabled, it compiles 400K lines of Luau code in 0.5 seconds on a single core of a desktop Core i7 CPU. While bytecode optimizations are limited due to the flexibility of Luau code (e.g. `a * 1` may not be equivalent to `a` if `*` is overloaded through metatables), even in absence of type information Luau compiler can perform some optimizations such as "deep" constant folding across functions and local variables, perform upvalue optimizations for upvalues that aren't mutated, do analysis of builtin function usage, and some peephole optimizations on the resulting bytecode. In the future we plan to do bytecode-level inlining and possibly other code transformation.