Drop Jurassic from engine comparison benchmarks, add Okojo - #2653
Merged
Merged
Conversation
Jurassic is unmaintained and ES5-only, so it is removed from the engine comparison benchmark and replaced by Okojo 0.1.2-preview.1, a new low-allocation bytecode engine for .NET 10 (https://github.com/akeit0/okojo). - Two lanes mirror the existing convention: `Okojo` builds a fresh runtime and executes the source each iteration; `Okojo_Prepared` reuses the parsed program (Okojo's realm-independent artifact) and compiles+runs the bytecode against each iteration's own fresh realm, so its gap to `Okojo` is parsing cost, just like `Jint_ParsedScript`. The compiled `JsScript` is realm-bound, so it is deliberately not cached across the fresh runtimes. - Okojo has no engine-level strict switch, so global strict mode is enabled with a leading `"use strict"` directive (verified enforced); all 21 scripts run under it. - Only the Okojo lanes were measured (same machine and .NET runtime as the 4.12.0 run) and merged into the table to keep thermal noise low; Jurassic rows are removed and, with every remaining engine parsing ES2015+, there are no more `NA` rows on the `-modern` scripts. - README refreshed: per-engine execution model note (interpreter vs IL compiler vs bytecode VM), updated comparative figures, and engine versions. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This was referenced Jul 15, 2026
This was referenced Jul 22, 2026
This was referenced Jul 31, 2026
This was referenced Aug 10, 2026
This was referenced Aug 18, 2026
This was referenced Aug 21, 2026
This was referenced Aug 28, 2026
This was referenced Sep 7, 2026
This was referenced Sep 21, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Jurassic hasn't seen much traction or updates and is ES5-only, so this drops it from the engine comparison benchmark and brings in a fresh contender: Okojo
0.1.2-preview.1, a new low-allocation, AOT-friendly bytecode engine for .NET 10.What changed
Directory.Packages.props/Jint.Benchmark.csproj/dependabot.yml— removeJurassic, addOkojo.EngineComparisonBenchmark— replace theJurassiclane with two Okojo lanes following the same rules as the other engines:Okojo— freshJsRuntime.Create()+Execute(source)each iteration (parses + compiles + runs), mirroring the plainJint/NilJS/YantraJSlanes.Okojo_Prepared— reuses the parsed program (JavaScriptParser.ParseScript→JsProgram, Okojo's realm-independent artifact) and compiles + runs the bytecode against each iteration's own fresh realm. Its gap toOkojois parsing cost — the direct analog ofJint_ParsedScript. The compiledJsScriptis realm-bound (JsCompiler.Compile(realm, program)), so it is intentionally not cached across the fresh runtimes, which would otherwise execute against a shared setup realm and violate the fresh-engine-per-iteration rule."use strict"directive (verified genuinely enforced); all 21 scripts run under it.Program.cssmoke-comparison lane swapped Jurassic → Okojo.Benchmarks
Only the Okojo lanes were re-measured (same machine + .NET runtime as the 4.12.0 run) and merged into the table, keeping thermal noise low; the other engines' numbers are unchanged. With Jurassic gone and every remaining engine parsing ES2015+, there are no more
NArows on the-modernscripts.Where Okojo lands: mid-pack. It never tops a row, is the fastest non-Jint engine on the
dromaeo-object-stringrows, and is a genuinely frugal allocator (it edges Jint on theobject-arrayworkloads), but it trails the field on regex-heavy work. Jint remains the fastest engine on 17 of 21 scripts and the fastest interpreter on all 21.The README also now notes how each engine executes — Jint (tree-walking AST interpreter), NiL.JS (interpreter), Okojo (bytecode VM interpreter), YantraJS (compiles to .NET IL) — since only the IL compiler runs ahead on tight numeric/call loops.
🤖 Generated with Claude Code