[Error] unhandlederror-PerfSampleError: by <<renderer>> in _readFromDomElements#workbench.desktop.main.js:47...

[vs-code-engineering]

Error Message

unhandlederror-PerfSampleError: by <<renderer>> in _readFromDomElements#workbench.desktop.main.js:478:28330

Stack Trace

    at _readFromDomElements (./src/vs/editor/browser/config/charWidthReader.ts:130:9)
    at read (./src/vs/editor/browser/config/charWidthReader.ts:48:8)
    at readCharWidths (./src/vs/editor/browser/config/charWidthReader.ts:140:16)
    at _actualReadFontInfo (./src/vs/editor/browser/config/fontMeasurements.ts:167:9)
    at readFontInfo (./src/vs/editor/browser/config/fontMeasurements.ts:128:8)
    at _readFontInfo (./src/vs/editor/browser/config/editorConfiguration.ts:157:11)
    at _computeOptions (./src/vs/editor/browser/config/editorConfiguration.ts:116:9)
    at _recomputeOptions (./src/vs/editor/browser/config/editorConfiguration.ts:103:9)
    at (anonymous) (./src/vs/editor/browser/config/editorConfiguration.ts:97:46)
    at _deliver (./src/vs/base/common/event.ts:1352:9)
    at _deliverQueue (./src/vs/base/common/event.ts:1371:9)
    at fire (./src/vs/base/common/event.ts:1384:1)
    at clearAllFontInfos (./src/vs/editor/browser/config/fontMeasurements.ts:57:8)
    at (anonymous) (./src/vs/workbench/contrib/codeEditor/electron-browser/displayChangeRemeasureFonts.ts:24:25)
    at queue (./src/vs/base/common/async.ts:239:1)
    at (anonymous) (./src/vs/base/common/async.ts:471:30)
    at (anonymous) (./src/vs/base/common/async.ts:406:11)

Raw Stack Trace (minified)

 	 at _readFromDomElements (out/vs/workbench/workbench.desktop.main.js:478:28330) 	 at read (out/vs/workbench/workbench.desktop.main.js:478:27310) 	 at O3i (out/vs/workbench/workbench.desktop.main.js:478:28470) 	 at _actualReadFontInfo (out/vs/workbench/workbench.desktop.main.js:478:30604) 	 at readFontInfo (out/vs/workbench/workbench.desktop.main.js:478:29612) 	 at _readFontInfo (out/vs/workbench/workbench.desktop.main.js:478:40516) 	 at _computeOptions (out/vs/workbench/workbench.desktop.main.js:478:39257) 	 at _recomputeOptions (out/vs/workbench/workbench.desktop.main.js:478:39093) 	 at (anonymous) (out/vs/workbench/workbench.desktop.main.js:478:38789) 	 at _deliver (out/vs/workbench/workbench.desktop.main.js:405:3177) 	 at _deliverQueue (out/vs/workbench/workbench.desktop.main.js:405:3305) 	 at fire (out/vs/workbench/workbench.desktop.main.js:405:3398) 	 at clearAllFontInfos (out/vs/workbench/workbench.desktop.main.js:478:28873) 	 at (anonymous) (out/vs/workbench/workbench.desktop.main.js:4962:47172) 	 at queue (out/vs/workbench/workbench.desktop.main.js:406:72954) 	 at (anonymous) (out/vs/workbench/workbench.desktop.main.js:406:75265) 	 at (anonymous) (out/vs/workbench/workbench.desktop.main.js:406:74676)

Details

Property	Value
Bucket ID	5556ca1a-6557-51f1-1393-218d4f55b42c
Version	1.118.0-insider
Commit	f2b51f3f
Last Seen	Sun Apr 26 2026 23:06:03 GMT+0000 (Coordinated Universal Time)
Platforms	Mac, Windows
Product	VSCode

---

This issue was automatically created from the VS Code Errors Dashboard

[vs-code-engineering]

🔍 Error Investigation

Summary

This is a PerfSampleError — a synthetic error generated by VS Code's built-in CPU profiler (profilingTelemetrySpec.ts), not a real exception or crash. The profiler detected that _readFromDomElements in charWidthReader.ts consumes significant CPU time during font remeasurement triggered by display change events (monitor connect/disconnect, resolution/DPI change). The error has been present across multiple versions (1.112.0, 1.117.0, 1.118.0 Insiders) since at least March 2026, indicating a long-standing performance characteristic rather than a recent regression.

Culprit Commit

No culprit commit was identified. There is no commit range analysis available (no regression scan comments on the issue), and the bucket history shows this error present across at least 4 different commits spanning versions 1.112.0 through 1.118.0 Insiders (March–April 2026). No recent changes to charWidthReader.ts, fontMeasurements.ts, or displayChangeRemeasureFonts.ts were found. This is a pre-existing performance hotspot, not a newly introduced regression.

Code Flow

sequenceDiagram
    participant OS as OS Display Change
    participant DCRF as DisplayChangeRemeasureFonts
    participant FM as FontMeasurements
    participant EC as EditorConfiguration
    participant CWR as DomCharWidthReader
    participant DOM as DOM Layout Engine

    OS->>DCRF: onDidChangeDisplay()
    DCRF->>FM: clearAllFontInfos()
    FM->>EC: onDidChange.fire()
    EC->>EC: _recomputeOptions()
    EC->>FM: readFontInfo(window, bareFontInfo)
    FM->>FM: _actualReadFontInfo()
    Note over FM: Creates ~40+ CharWidthRequests
    FM->>CWR: readCharWidths(window, bareFontInfo, requests)
    CWR->>CWR: _createDomElements()
    CWR->>DOM: document.body.appendChild(container)
    CWR->>CWR: _readFromDomElements()
    loop For each of ~40+ test elements
        CWR->>DOM: testElement.offsetWidth
        Note over DOM: ⚠️ Forces synchronous<br/>layout/reflow per read
    end
    Note over CWR: 💥 PerfSampleError reported<br/>by CPU profiler

Loading

Affected Files

File	Role
src/vs/editor/browser/config/charWidthReader.ts	Performance hotspot — _readFromDomElements() reads offsetWidth for each of ~40+ test elements, forcing synchronous layout reflow
src/vs/editor/browser/config/fontMeasurements.ts	Orchestrates font measurement — _actualReadFontInfo() creates all char width requests and calls readCharWidths()
src/vs/editor/browser/config/editorConfiguration.ts	Listens to FontMeasurements.onDidChange and triggers _recomputeOptions() → _readFontInfo()
src/vs/workbench/contrib/codeEditor/electron-browser/displayChangeRemeasureFonts.ts	Trigger — calls FontMeasurements.clearAllFontInfos() on display change events (with 2s throttle)
src/vs/platform/profiling/common/profilingTelemetrySpec.ts	Creates PerfSampleError and reports it via errorHandler.onUnexpectedError()

Repro Steps

1. Open VS Code with an editor visible
2. Trigger a display change event — connect/disconnect an external monitor, change display resolution, or change DPI scaling
3. Wait ~2 seconds for the ThrottledDelayer in DisplayChangeRemeasureFonts to fire
4. The font cache is cleared, and all editors remeasure fonts synchronously
5. If the CPU profiler is running and samples during _readFromDomElements, a PerfSampleError is reported

This is more likely to trigger on slower machines or when many editors are open simultaneously, as each editor triggers a _recomputeOptions() call that re-reads font info.

Fix Proposal

Fix location: src/vs/editor/browser/config/charWidthReader.ts → _readFromDomElements()
Approach: The current implementation reads offsetWidth in a loop for ~40+ elements, each of which may force a layout reflow. The performance could be improved by:

1. Batching DOM reads: Read all offsetWidth values in a single pass after the container is attached to the DOM (the current code already does this — the issue is the sheer number of elements). Consider reducing the number of test characters or combining measurements.
2. Using requestAnimationFrame: Make the font measurement asynchronous so it doesn't block the main thread. _readFromDomElements could return a Promise that resolves after the next frame, avoiding synchronous layout thrashing.
3. Deferred remeasurement: Instead of immediately remeasuring all editors on display change, batch and coalesce the remeasurements with a larger debounce or make them lazy (only remeasure when an editor becomes visible).

Note: Since this is a performance profiling sample rather than a crash, the priority depends on how frequently it affects real-world user experience during display changes.

Recommended Owner

@alexdima — owns editor rendering (text, minimap, decorations, content widgets, etc.) per working areas. charWidthReader.ts and fontMeasurements.ts are core editor rendering/configuration infrastructure.

Generated by errors-investigate · ● 5.2M · ◷

[vs-code-engineering]

Stable Release Anomaly Details

These additional error buckets are tracked by this issue (v1.119.0):

Bucket ID	Users	Type
aa815fdf	937	spike (937x)
80750f99	195	spike (195x)

• Previous stable: 1.118.1
• Current stable: 1.119.0

These PerfSampleError buckets show a massive spike in 1.119.0 stable (from 1 user each in 1.118.1 to 937 and 195 users respectively).

Generated by errors-stable-scan · ● 7.8M · ◷