After testing several kinds of operations, it seems like LSL-Luau has questionable average performance compared to LSL-Mono - computations are slower, but data stuctures fare better. Many of the situations apply to pure Luau as well, so they may be just a limitation of the VM itself rather than a problem with LSL being compiled to it.
I'm aware Luau's flexibility and better data handling have to come at a cost, but I'm mostly bringing this up in case there are things that could still be fine-tuned, especially to get LSL-Luau average performance up to par with LSL-Mono. I am also aware that most peoples' primary scripting concern is probably not the raw numeric throughput, but for many of my projects it is.
The positives:
  1. Tables are naturally much, much faster than lists: creating and altering tables is orders of magnitude faster than altering lists. Creating lists under LSL-Luau is faster than LSL-Mono, so they appear to be table-backed?
  2. Buffers are also a faster alternative to lists, when using pure Luau.
  3. String operations are faster, both for Luau and LSL-Luau. This includes altering strings (yes I know they're not mutable).
  4. Many of the math library calls are faster under pure Luau than the LSL/LL equivalents.
The negatives:
  1. Integer/floating point math and bit ops - the extra degradation in LSL-Luau from implicit conversions when e.g. adding an integer to a float already has its separate post already. Can be up to 3-4x slower (very rough estimates) under LSL-Luau, 1.3x slower under Luau. Despite Luau's own claims, the lack of integer data types appears to have an effect.
  2. Function calls. Even the most basic function that does nothing but return is slower to call under Luau, whether as a global definition or from a table. Under LSL-Luau, they're even slower. Calling LL library functions as close to a no-op as possible (llSleep(0) is what I used) is also slower under Luau and LSL-Luau, though as stated above, some of the native Luau library calls are better. I was hoping to replace performance-critical if/else cascades+inline computations with function tables in Luau, but that might only end up being slower in practice.
  3. Reading lists under LSL-Luau seems to be slower than LSL-Mono. Something feels off about that, if they're backed by tables which should be faster? Since reading lists happens quite a lot more than creating them, this could be beneficial to improve.
  4. Altering lists under LSL-Luau is also slower (yes, I know lists are also not mutable, e.g. doing l = llListReplaceList(l, ...)). This feels a little strange as well, since crafting those lists by appending things is faster.