Wheels 2.x > 4.x Performance Comparison

[chapmandu]

Hi Team,

I have done a preliminary port of my application from 2.5 > 4.0.3. I am just wanting to know if there has been any performance comparisons or load testing done between the two versions. My initial test run is showing a considerably slower test suite execution.

Wheels 2.5 (RocketUnit)
Finished Tue Jun 16 2026 10:05:50 (Took 274 Seconds)

Wheels 4.0.3 (RocketUnit)
The full run took 1599 seconds (~27 minutes) — 1574 pass / 5 skip / 0 fail, finished at 08:03:19 yesterday.

Thanks for all your hard work on wheels framework. 💪

Regards,
Adam

[wheels-bot]

Wheels Bot — Triage

Classified as bug (performance regression). The report is framed as a question, but it carries a clear measured regression: the same RocketUnit suite runs in 274s on 2.5 vs 1599s on 4.0.3 — roughly a 6x slowdown on a like-for-like runner. "What happened / what I expected" are both present, which is the bug shape.

Suspected layer

`controller` — see `.ai/wheels/controllers/` for canonical patterns. The dominant cost in a 1574-test RocketUnit run is per-request lifecycle overhead, which compounds across every test. That's exactly where the framework's recent perf work landed (`ef02be9`: cold-start warm-up, O(1) protected-method gate, schema cache, debug-bar slimming). The ORM/`model` layer (finder + schema-cache overhead) is a plausible secondary contributor and should be profiled alongside.

Fix sketch

No single file is implicated yet — this needs profiling before a fix can be scoped. Propose-fix should first reproduce against a representative request path and identify which per-request hotspots regressed (debug-bar rendering in `testing`, the protected-method gate in `$callAction`, schema lookups, cold-start warm-up). Several of these were already addressed in `ef02be9`, which post-dates 4.0.3 — so part of the remedy may be "confirm the next release includes these fixes" rather than new code. Likely touch points are the request-dispatch/controller lifecycle and model schema-cache paths.

Confidence: `low`

The report has no profiling or operation-level isolation, the slowdown could span multiple layers, and the symptom is environment-/suite-dependent — so the fix shape isn't derivable from the issue body, and low intentionally does not auto-trigger a fix PR.

<!-- wheels-bot:triage:3213 -->
<!-- wheels-bot:triage-class:bug -->

[bpamiri]

@chapmandu Adam, would you be open to sharing a codebase to demonstrate the issue so I can run perf mon on it.

[chapmandu]

Hi Peter,

Sorry but I can't share my employer's IP but would happily run some performance analysis on the code and share any findings.

Are there any specific tools you'd like to run or metrics to gather? I'm running latest stable Lucee 5 on Tomcat.

Regards,
Adam

[bpamiri]

Ah, understood. I just need a rocketunit test suite. I'll create that on this side. But just out of curiosity, can you run your code on Lucee 7 to see if the results are any different.

[bpamiri]

Hi @chapmandu — we found and fixed the main culprit. 🎯

Root cause: it wasn't per-test overhead, it was per-object overhead. Every model().new() and every row returned by a finder re-ran the framework's mixin integration from scratch — a directory scan of vendor/wheels/model/, a createObject + getMetaData for each of its ~18 files, and a re-resolve of all ~231 mixed-in methods — on every instance. A RocketUnit suite materializes huge numbers of objects, so it compounded badly. (Controller/Mapper had the same pattern.)

Fix (#3236, merged to develop): that work is now done once per application and reused. Measured on Lucee 7 + SQLite: model-instance creation dropped ~1.8× (2772 ms → 1513 ms for 2,000 instances) and the full framework suite went 33.3 s → ~22 s, with no behavior change. The win should be larger for an instance-heavy app suite like yours.

Could you re-check on the bleeding-edge build? The fix is on develop now (the 4.0.6 snapshot line — not in 4.0.5 stable yet), which the bleeding-edge channel tracks. Easiest path is via the Wheels CLI:

scoop install wheels-be          # bleeding-edge channel (Windows; brew/apt have a -be channel too)
wheels upgrade apply             # swap your app's vendor/wheels to the BE framework (try `wheels upgrade check` first)
wheels server start

Then re-run your RocketUnit suite and let us know the new timing vs the 1599 s you saw on 4.0.3. A couple of notes:

• wheels upgrade apply swaps vendor/wheels/ in place — do it on a branch/copy so it's easy to roll back.
• If you can, the per-suite number is most informative; even a rough before/after helps confirm it lands for your workload.

There's also a follow-up in progress that profiles ~5.8× on instance creation (cloning a pre-built prototype instead of re-mixing) — it needs cross-engine validation before it can ship, so it'll come as a separate PR. But #3236 alone should already be a substantial improvement. 🙏

EDIT - The separate PR turned out to be a deadend. I'll look at more optimization that could be had but the ~5.8x increase didn't pan out. --Peter

---

Generated by Claude Code

[bpamiri]

@chapmandu Adam — a substantial update, and a correction to my earlier optimistic read.

You were right. I reproduced the remaining gap with a v2.5.0 vs current develop A/B on one machine — same Lucee 7 engine, same workload shape as your suite (4 RocketUnit packages × 10 tests, instance-heavy), warmed runs:

• Per-object cost — 3000 × model().new() + 3 property sets: ~263 ms on 2.5.0 vs ~1180–1350 ms on develop (~4.5–5× slower today).
• Full 40-test suite: ~89 ms on 2.5.0 vs ~221 ms on develop (~2.5× slower).

So your 6× observation on Lucee 5 was a real measurement of the same cliff, not an environment artifact. What has shipped so far: 4.0.6 includes #3210 (per-request) and #3236 (per-object mixin caching) — those took 4.0.3 → develop from ~1290 ms to ~1180 ms (~12%) on the same loop, but 4.x's per-object path is still far heavier than 2.5's, and I'm treating the remaining gap as an open bug rather than a tuning artifact.

While benchmarking I also found two separate 4.x bugs on Lucee 7 — a flaky bare NPE in model instantiation after a fresh boot, and a RocketUnit runner bug where any failing test crashes the whole suite. Both are filed and being fixed; I'll link them here once the numbers are up.

Next from our side: profile and close the per-object gap, then re-measure with this same rig. If you get a chance to re-run your suite on 4.0.6+, even a rough before/after would help confirm the delta lands where expected. Thanks again for the report — it's driving real work.