Skip to content

Drop Jurassic from engine comparison benchmarks, add Okojo - #2653

Merged
lahma merged 1 commit into
sebastienros:mainfrom
lahma:jurassic-to-okojo
Jul 12, 2026
Merged

lahma merged 1 commit into
sebastienros:mainfrom
lahma:jurassic-to-okojo

Conversation

@lahma

@lahma lahma commented Jul 12, 2026

Copy link
Copy Markdown
Collaborator

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 — remove Jurassic, add Okojo.
  • EngineComparisonBenchmark — replace the Jurassic lane with two Okojo lanes following the same rules as the other engines:
    • Okojo — fresh JsRuntime.Create() + Execute(source) each iteration (parses + compiles + runs), mirroring the plain Jint / NilJS / YantraJS lanes.
    • 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 to Okojo is parsing cost — the direct analog of Jint_ParsedScript. The compiled JsScript is 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.
  • Okojo has no engine-level strict switch, so global strict mode is enabled with a leading "use strict" directive (verified genuinely enforced); all 21 scripts run under it.
  • Program.cs smoke-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 NA rows on the -modern scripts.

Where Okojo lands: mid-pack. It never tops a row, is the fastest non-Jint engine on the dromaeo-object-string rows, and is a genuinely frugal allocator (it edges Jint on the object-array workloads), 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

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>
@lahma
lahma merged commit 546ccae into sebastienros:main Jul 12, 2026
4 checks passed
@lahma
lahma deleted the jurassic-to-okojo branch July 12, 2026 18:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant