Bob Nystrom
ca8e97521a
- Add Alexander Roper to AUTHORS file with newline fix for Starbeamrainbowlabs entry - Replace placeholder embedding API docs with full guide covering static/dynamic linking and source inclusion - Update codebase line count from 5,000 to 7,000 lines in README and index - Fix relative documentation links to absolute URLs in README - Add CSS styling for preprocessor directive syntax highlighting - Update Xcode project file references and CopyFiles build phase UUID - Adjust delta_blue benchmark expected value from 7032700 to 14065400 - Improve markdown header detection regex in generate_docs.py to avoid matching #include - Refactor metrics.py to exclude curly brace lines from code line counting - Add TEST_HEADERS dependency to test object compilation in wren.mk - Remove NULL parameter from runFile call in main.c - Refactor vm.c to support WrenBindForeignClassFn callback and rename externalBindForeign to bindMethodFn - Update vm.h to remove bindForeign parameter documentation and adjust runFile signature
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.