Skip to content

Refresh engine comparison benchmark results#2561

Merged
lahma merged 1 commit into
sebastienros:mainfrom
lahma:refresh-engine-benchmarks-2026-06
Jun 30, 2026
Merged

Refresh engine comparison benchmark results#2561
lahma merged 1 commit into
sebastienros:mainfrom
lahma:refresh-engine-benchmarks-2026-06

Conversation

@lahma

@lahma lahma commented Jun 30, 2026

Copy link
Copy Markdown
Collaborator

Re-runs the EngineComparison suite on the current main (14 commits past v4.10.1) and refreshes Jint.Benchmark/README.md with a fresh table, updated highlights, and a regression-focused summary.

Context

The competitor engine versions are unchanged since v4.10.1 (Jurassic 3.2.9, NiL.JS 2.6.1722, YantraJS.Core 1.2.406), so every movement in the table is Jint's own allocation/dispatch tuning landed since the tag: object-literal & constructor shapes (#2552, #2553), in-object properties (#2559), source-generated built-in shapes (#2554#2557), the write-side (#2546) and prototype-method (#2558) inline caches, recursion env pooling (#2549), and zero-copy SlicedString search (#2547).

Regression check (the headline ask)

I ran a v4.10.1-vs-HEAD Jint-only A/B back-to-back in a single thermal window (both Jint re-parse and Jint_ParsedScript prepared paths), on top of the full all-engines run used for the table. Verdict: no alarming regressions.

  • Real, consistent improvements (move the same way in both execution paths): dromaeo-object-array −12.7% (17.0 → 15.1 ms), dromaeo-object-array-modern −3%/−12%, array-stress −6.5%/−12% — all attributable to the prototype-method inline cache (Prototype-method inline cache for obj.method resolved on the direct prototype #2558).
  • Allocation is flat (within ±2%) on every script except linq-js, which rises ~28 KB/op (175 → 203 KB prepared) — the one workload that builds many distinct object shapes per run, so the new shape metadata is rebuilt each operation. It is still 5× below YantraJS and 13× below NiL.JS.
  • Apparent time slowdowns are measurement noise. stopwatch, dromaeo-object-string and dromaeo-string-base64 show deltas in the ±5–8% band, but they flip sign between the re-parse and prepared paths within the same run (e.g. stopwatch is +4.5% prepared / −6.7% re-parse), and intra-run the two paths disagree by more than the delta itself. These are call-dispatch-bound, high-variance scripts; the deltas are within their run-to-run noise floor.

Method

  • Host: AMD Ryzen 9 5950X, .NET 10.0.9, BenchmarkDotNet v0.15.8 (DefaultJob), same machine as the previous refresh.
  • Table = full all-engines run on main @ 9c0266e6c.
  • Regression A/B = v4.10.1 worktree vs HEAD, Jint/Jint_ParsedScript only, adjacent runs.

🤖 Generated with Claude Code

Re-run the EngineComparison suite on the current `main` (14 commits past
v4.10.1) and refresh Jint.Benchmark/README.md. Competitor engine versions
are unchanged since the tag (Jurassic 3.2.9, NiL.JS 2.6.1722,
YantraJS.Core 1.2.406), so all movement is Jint's own allocation and
dispatch tuning (object-literal/constructor shapes, in-object properties,
built-in shapes, write-side + prototype-method inline caches).

Headline changes vs the previous table: dromaeo-object-array -12.7%
(15.1 ms), array-stress -6.5%; allocation flat everywhere except a
~28 KB/op rise on linq-js (the one shape-diverse workload, still 5-13x
below the field). A v4.10.1-vs-HEAD Jint-only A/B in a single thermal
window confirms no alarming regressions: the apparent stopwatch /
object-string / base64 slowdowns flip sign between the re-parse and
prepared paths and sit within run-to-run variance.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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