Skip to content

perf(controller): apply a per-class precomputed method struct instead of the per-instance mixin loop #4149

Closed

Description

@bpamiri

Measured on: RustCFML v0.693.0 (the CI pin), develop 0255f0d53, production mode, SQLite, Apple M3 Ultra.

Problem

Every request builds a new controller instance, and Controller.init() mixes in the framework's controller and view methods one at a time. #2897 / #3236 already cache the integration plan per base path. But the replay loop in $integrateFunctions (vendor/wheels/Controller.cfc) still runs per instance: about 550 methods, each with 2 StructKeyExists checks and 2 struct writes (variables and this).

Measured on RustCFML:

Measurement Result
Controller instance on the request path: controller("Products", {controller: "products", action: "index"}) 4.47 ms (median of 3 × 100 calls)
CFML sampling profiler, a renderText("ok") action (400 requests) Controller.init → $integrateFunctions is 47% of request samples
CFML sampling profiler, a 50-row list page (440 requests) 15.7% of request samples
Warm request latency, dispatch only (renderText) 9.03 ms median, against a 0.69 ms bare-engine page
Copying the same 550 method references into two structs with a CFML loop 1,146 µs
The same copy with 2× StructAppend(target, source, false) 43 µs (27x faster)

Not measured yet: Lucee, Adobe or BoxLang. The loop runs on every engine, so the relative cost there is worth checking.

Proposal

Precompute, once per controller class (alongside the cached plan), the final struct of name → ref entries to add, plus the super<name> aliases. That struct is the same for every instance of a class, because inheritance and the mixin-override set are fixed per class. Each new instance then applies it with StructAppend(variables, precomputed, false) and StructAppend(this, precomputed, false) instead of the per-method loop.

The same pattern may apply to Model.cfc's $integrateFunctions for returnAs="objects" rows.

Constraints

Acceptance

Activity

  1. added this to the v4.3.0 milestone on Oct 3, 2026
  2. added
    performancePerformance work (profiling, hot-path optimization)
    on Oct 3, 2026
  3. modified the milestones: v4.3.0, v4.2.0 on Oct 5, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    performancePerformance work (profiling, hot-path optimization)

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions