Bob Nystrom
2387d4dc31
Previously, fibers had a hard-coded limit to how big their stack size is. This limit exists in two forms: the number of distinct call frames (basically the maximum call depth), and the number of unique stack slots. This fixes the first half of this by dynamically allocating the call frame array and growing it as needed. This makes new fibers smallers since they can start with a very small array. Checking and growing as needed doesn't noticeably regress the perf on the other benchmarks, and it makes a new fiber benchmark about 45% faster. The stack array is still hardcoded, but that will be in another commit.
The benchmarks in here attempt to faithfully implement the exact same algorithm in a few different languages. We're using Lua, Python, and Ruby for comparison here because those are all in Wren's ballpark: dynamically-typed, object-oriented, bytecode-compiled.
A bit about each benchmark:
binary_trees
This benchmark stresses object creation and garbage collection. It builds a few big, deeply nested binaries and then traverses them.
fib
This is just a simple naïve Fibonacci number calculator. It was the first benchmark I wrote when Wren supported little more than function calls and arithmetic. It isn't particularly representative of real-world code, but it does stress function call and arithmetic.
for
This microbenchmark just tests the performance of for loops. Not too useful, but i used it when implementing for in Wren to make sure it wasn't too far off the mark.
method_call
This is the most useful benchmark: it tests dynamic dispatch and polymorphism. You'll note that the main iteration loop is unrolled in all of the implementations. This is to ensure that the loop overhead itself doesn't dwarf the method call time.