Skip to content

perf(runtime-dom): avoid event handler array allocations#14828

Open
leno23 wants to merge 1 commit into
vuejs:mainfrom
leno23:perf/runtime-dom-event-array-handlers
Open

perf(runtime-dom): avoid event handler array allocations#14828
leno23 wants to merge 1 commit into
vuejs:mainfrom
leno23:perf/runtime-dom-event-array-handlers

Conversation

@leno23
Copy link
Copy Markdown
Contributor

@leno23 leno23 commented May 16, 2026

Summary

  • Avoid per-dispatch Array.map and wrapper closure allocations for runtime-dom event handler arrays.
  • Preserve stopImmediatePropagation() behavior by stopping later handlers in the same array.
  • Add regression coverage for the allocation path and stop-immediate behavior.
  • Add a runtime-dom event dispatch benchmark for single vs multiple handlers.

Test Plan

  • GitHub Actions passed on this PR:
    • test / unit-test
    • test / unit-test-windows
    • test / lint-and-test-dts
    • test / e2e-test
  • Patch syntax/hunk counts were validated locally before committing.
  • git apply --check was run against the fetched upstream target files before creating this branch.
  • Not run locally: this change was prepared via GitHub API without a full local checkout.

Suggested benchmark command:

pnpm vitest bench packages/runtime-dom/__benchmarks__/events.bench.ts

Summary by CodeRabbit

  • Tests

    • Added test coverage for multiple event handlers attached to a single element
    • Added tests verifying proper event propagation control behavior
  • Chores

    • Optimized event dispatch mechanism for improved runtime performance
    • Added performance benchmarks for event handler scenarios

Review Change Stack

@coderabbitai
Copy link
Copy Markdown

coderabbitai Bot commented May 16, 2026

📝 Walkthrough

Walkthrough

The PR refactors event dispatch in runtime-dom by inlining array handler processing directly into createInvoker, replacing prior delegation to a helper function. Tests validate invocation and propagation semantics; benchmarks measure the new flow's performance for single and multiple handlers.

Changes

Event Handler Array Processing

Layer / File(s) Summary
Event handler array inlining
packages/runtime-dom/src/modules/events.ts
createInvoker's event handler now branches on invoker.value: if an array, patches stopImmediatePropagation, iterates handlers with early exit, and invokes each via callWithAsyncErrorHandling; if not an array, invokes the single handler once. The patchStopImmediatePropagation helper is removed.
Event handler array tests
packages/runtime-dom/__tests__/patchProps.spec.ts
Two new tests validate that patchProp with multiple click handlers invokes each handler without calling array map, and that calling stopImmediatePropagation in the first handler prevents later handlers from running.
Event dispatch benchmarks
packages/runtime-dom/__benchmarks__/events.bench.ts
Two benchmarks measure patchProp click dispatch performance: one for single handlers and one for handler arrays, each tracking invocation count via dispatchEvent.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

Poem

🐰 A sprightly shuffle through events today,
Array handlers now flow in a cleaner way—
No helper lost, but inlined with care,
Tests vouch for safety, benchmarks laid bare! ✨

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (4 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title clearly and accurately summarizes the main performance optimization: avoiding array allocations for event handlers in runtime-dom event dispatch.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

Tip

💬 Introducing Slack Agent: The best way for teams to turn conversations into code.

Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.

  • Generate code and open pull requests
  • Plan features and break down work
  • Investigate incidents and troubleshoot customer tickets together
  • Automate recurring tasks and respond to alerts with triggers
  • Summarize progress and report instantly

Built for teams:

  • Shared memory across your entire org—no repeating context
  • Per-thread sandboxes to safely plan and execute work
  • Governance built-in—scoped access, auditability, and budget controls

One agent for your entire SDLC. Right inside Slack.

👉 Get started


Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@pkg-pr-new
Copy link
Copy Markdown

pkg-pr-new Bot commented May 16, 2026

Open in StackBlitz

@vue/compiler-core

pnpm add https://pkg.pr.new/@vue/compiler-core@14828
npm i https://pkg.pr.new/@vue/compiler-core@14828
yarn add https://pkg.pr.new/@vue/compiler-core@14828.tgz

@vue/compiler-dom

pnpm add https://pkg.pr.new/@vue/compiler-dom@14828
npm i https://pkg.pr.new/@vue/compiler-dom@14828
yarn add https://pkg.pr.new/@vue/compiler-dom@14828.tgz

@vue/compiler-sfc

pnpm add https://pkg.pr.new/@vue/compiler-sfc@14828
npm i https://pkg.pr.new/@vue/compiler-sfc@14828
yarn add https://pkg.pr.new/@vue/compiler-sfc@14828.tgz

@vue/compiler-ssr

pnpm add https://pkg.pr.new/@vue/compiler-ssr@14828
npm i https://pkg.pr.new/@vue/compiler-ssr@14828
yarn add https://pkg.pr.new/@vue/compiler-ssr@14828.tgz

@vue/reactivity

pnpm add https://pkg.pr.new/@vue/reactivity@14828
npm i https://pkg.pr.new/@vue/reactivity@14828
yarn add https://pkg.pr.new/@vue/reactivity@14828.tgz

@vue/runtime-core

pnpm add https://pkg.pr.new/@vue/runtime-core@14828
npm i https://pkg.pr.new/@vue/runtime-core@14828
yarn add https://pkg.pr.new/@vue/runtime-core@14828.tgz

@vue/runtime-dom

pnpm add https://pkg.pr.new/@vue/runtime-dom@14828
npm i https://pkg.pr.new/@vue/runtime-dom@14828
yarn add https://pkg.pr.new/@vue/runtime-dom@14828.tgz

@vue/server-renderer

pnpm add https://pkg.pr.new/@vue/server-renderer@14828
npm i https://pkg.pr.new/@vue/server-renderer@14828
yarn add https://pkg.pr.new/@vue/server-renderer@14828.tgz

@vue/shared

pnpm add https://pkg.pr.new/@vue/shared@14828
npm i https://pkg.pr.new/@vue/shared@14828
yarn add https://pkg.pr.new/@vue/shared@14828.tgz

vue

pnpm add https://pkg.pr.new/vue@14828
npm i https://pkg.pr.new/vue@14828
yarn add https://pkg.pr.new/vue@14828.tgz

@vue/compat

pnpm add https://pkg.pr.new/@vue/compat@14828
npm i https://pkg.pr.new/@vue/compat@14828
yarn add https://pkg.pr.new/@vue/compat@14828.tgz

commit: cc5d253

@github-actions
Copy link
Copy Markdown

Size Report

Bundles

File Size Gzip Brotli
runtime-dom.global.prod.js 106 kB (+13 B) 40 kB (-4 B) 35.9 kB (-18 B)
vue.global.prod.js 164 kB (+13 B) 60 kB (-1 B) 53.4 kB (+5 B)

Usages

Name Size Gzip Brotli
createApp (CAPI only) 48.7 kB (+13 B) 18.9 kB (+1 B) 17.3 kB (-10 B)
createApp 56.8 kB (+15 B) 22 kB (-6 B) 20.1 kB (-5 B)
createSSRApp 61.1 kB (+13 B) 23.7 kB (-6 B) 21.6 kB (-7 B)
defineCustomElement 63 kB (+13 B) 23.9 kB (-5 B) 21.8 kB (-1 B)
overall 71.6 kB (+13 B) 27.4 kB (-3 B) 25 kB (+40 B)

@leno23 leno23 force-pushed the perf/runtime-dom-event-array-handlers branch from bf46e08 to cc5d253 Compare May 16, 2026 05:04
@leno23 leno23 marked this pull request as ready for review May 16, 2026 15:25
Copy link
Copy Markdown

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: cc5d253fa5

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

originalStop.call(e)
;(e as any)._stopped = true
}
for (let i = 0; i < value.length; i++) {
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Snapshot handler array length before iterating

Iterating with i < value.length makes dispatch observe in-loop mutations to the same handler array, which changes previous behavior and can hang the event loop. If a handler appends to value (e.g. pushes itself or another callback), the loop will keep extending and newly added handlers run in the same dispatch (or never terminate), whereas the prior map path implicitly iterated a fixed snapshot. This is user-reachable whenever the listener array is reused/mutated from inside a handler.

Useful? React with 👍 / 👎.

Copy link
Copy Markdown

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick comments (2)
packages/runtime-dom/src/modules/events.ts (1)

122-133: ⚡ Quick win

Avoid per-handler args-array allocations in the hot loop.

This path still allocates [e] for every handler invocation. Hoist it once per dispatch to keep the allocation reduction goal intact.

♻️ Proposed fix
     if (isArray(value)) {
       const originalStop = e.stopImmediatePropagation
       e.stopImmediatePropagation = () => {
         originalStop.call(e)
         ;(e as any)._stopped = true
       }
+      const args = [e]
       for (let i = 0; i < value.length; i++) {
         if ((e as any)._stopped) {
           break
         }
         const handler = value[i]
         if (handler) {
           callWithAsyncErrorHandling(
             handler,
             instance,
             ErrorCodes.NATIVE_EVENT_HANDLER,
-            [e],
+            args,
           )
         }
       }
     } else {
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@packages/runtime-dom/src/modules/events.ts` around lines 122 - 133, The
hot-loop currently allocates a new args array for every handler call by passing
[e] inline; hoist that allocation out of the loop by creating a single const
args = [e] immediately before the for loop and pass args into
callWithAsyncErrorHandling instead. Update the loop in events.ts where value
(the handlers array) is iterated and ensure callWithAsyncErrorHandling(handler,
instance, ErrorCodes.NATIVE_EVENT_HANDLER, args) is used so no per-handler array
allocations occur.
packages/runtime-dom/__benchmarks__/events.bench.ts (1)

5-22: ⚡ Quick win

Benchmark body currently mixes setup cost with dispatch cost.

Given the bench names, consider moving createElement + patchProp setup outside the timed callback so the metric isolates dispatch performance.

📊 Proposed refactor
 describe('runtime-dom events', () => {
+  const singleEl = document.createElement('button')
+  let singleCount = 0
+  patchProp(singleEl, 'onClick', null, () => singleCount++)
+
+  const multiEl = document.createElement('button')
+  let multiCount = 0
+  patchProp(multiEl, 'onClick', null, [
+    () => multiCount++,
+    () => multiCount++,
+    () => multiCount++,
+    () => multiCount++,
+  ])
+
   bench('dispatch click with single handler', () => {
-    const el = document.createElement('button')
-    let count = 0
-    patchProp(el, 'onClick', null, () => count++)
-    el.dispatchEvent(new Event('click'))
+    singleEl.dispatchEvent(new Event('click'))
   })
 
   bench('dispatch click with multiple handlers', () => {
-    const el = document.createElement('button')
-    let count = 0
-    patchProp(el, 'onClick', null, [
-      () => count++,
-      () => count++,
-      () => count++,
-      () => count++,
-    ])
-    el.dispatchEvent(new Event('click'))
+    multiEl.dispatchEvent(new Event('click'))
   })
 })
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@packages/runtime-dom/__benchmarks__/events.bench.ts` around lines 5 - 22, The
benchmark callbacks currently include setup (document.createElement + patchProp)
which contaminates dispatch timing; extract the setup for both benches so only
el.dispatchEvent(new Event('click')) runs inside each bench callback: create the
button element once per bench, call patchProp(el, 'onClick', null, ...)
beforehand (for the single-handler and the array-of-handlers cases), then have
the bench callback simply call el.dispatchEvent(...). Reference the existing
bench(...) invocations, document.createElement, patchProp, and el.dispatchEvent
when making the change.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In `@packages/runtime-dom/__benchmarks__/events.bench.ts`:
- Around line 5-22: The benchmark callbacks currently include setup
(document.createElement + patchProp) which contaminates dispatch timing; extract
the setup for both benches so only el.dispatchEvent(new Event('click')) runs
inside each bench callback: create the button element once per bench, call
patchProp(el, 'onClick', null, ...) beforehand (for the single-handler and the
array-of-handlers cases), then have the bench callback simply call
el.dispatchEvent(...). Reference the existing bench(...) invocations,
document.createElement, patchProp, and el.dispatchEvent when making the change.

In `@packages/runtime-dom/src/modules/events.ts`:
- Around line 122-133: The hot-loop currently allocates a new args array for
every handler call by passing [e] inline; hoist that allocation out of the loop
by creating a single const args = [e] immediately before the for loop and pass
args into callWithAsyncErrorHandling instead. Update the loop in events.ts where
value (the handlers array) is iterated and ensure
callWithAsyncErrorHandling(handler, instance, ErrorCodes.NATIVE_EVENT_HANDLER,
args) is used so no per-handler array allocations occur.

ℹ️ Review info
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: d77a28ed-4eb2-4916-88f5-8fc6d8e8aeca

📥 Commits

Reviewing files that changed from the base of the PR and between 1ce598e and cc5d253.

📒 Files selected for processing (3)
  • packages/runtime-dom/__benchmarks__/events.bench.ts
  • packages/runtime-dom/__tests__/patchProps.spec.ts
  • packages/runtime-dom/src/modules/events.ts

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