Steps to reproduce
Performance: ~280 ms renderer stall every ~2 seconds in large vault caused by getAllPropertyInfos()
Environment
Obsidian: 1.13.7
Installer: 1.13.7
OS: Windows 11 Pro 10.0.26200
Restricted mode: On
Community plugins: None
Community theme: None
CSS snippets: 5 enabled
Vault: approximately 10,500 files, with many Markdown files
Reproduced with the vault stored locally on an NTFS SSD
Expected result
Having a huge Vault while still maintaining smooth operation.
Actual result
While continuously typing in a Markdown note, Obsidian produces a clearly perceptible UI freeze approximately every 2 seconds.
This only becomes noticeable with the large vault. A much smaller vault on the same PC remains completely smooth.
The problem is strongly correlated with completion of the vault metadata/cache initialization:
While rebuilding/initializing the vault cache, typing is smooth.
As soon as initialization finishes, the recurring ~2 second freezes return.
Manually running Rebuild vault cache reproduces this behavior: the freezes disappear during the rebuild and return immediately after it completes.
Environment
SYSTEM INFO:
Obsidian version: 1.13.7
Installer version: 1.13.7
Operating system: Windows 11 Pro 10.0.26200
Login status: not logged in
Language: en
Insider build toggle: off
Live preview: on
Base theme: adapt to system
Community theme: none
Snippets enabled: 5
Restricted mode: on
Additional information
DevTools Performance trace
A DevTools Performance recording captured 7 recurring long tasks on CrRendererMain after the profiler startup event.
Long-task durations:
277.435 ms
281.570 ms
281.068 ms
282.310 ms
278.346 ms
281.162 ms
278.199 ms
Average duration: 280.013 ms
Interval between these stalls:
1.994550 s
2.013542 s
2.012355 s
2.013177 s
2.011789 s
2.013597 s
Average interval: 2.009835 s
This matches the observed typing freezes almost exactly.
CPU profile inside those seven stalls
There were 2,190 CPU samples during the recurring long tasks:
t.getAllPropertyInfos 1,944 samples 88.77 %
t.updatePropertyInfoCache 175 samples 7.99 %
Garbage Collector 41 samples 1.87 %
(program) 29 samples 1.32 %
other 1 sample
getAllPropertyInfos() + updatePropertyInfoCache() therefore account for approximately 96.76% of all CPU samples during the freezes.
The trace identifies both functions in:
app://obsidian.md/app.js
Relevant call/update path
The app code included in the trace shows that the metadata type manager registers:
metadataCache “finished”
↓
updatePropertyInfoCache()
↓
metadataCache.getAllPropertyInfos()
getAllPropertyInfos() iterates the vault’s fileCache, obtains cached metadata/frontmatter for files, and processes property information.
Therefore, after the metadata cache reports finished, a property-information refresh appears to perform work proportional to the size of the vault.
In this vault that work currently occupies the renderer main thread for approximately 280 ms.
Reproduction
Open a large vault (~10,000 files).
Wait until vault initialization/cache processing has completely finished.
Open a normal Markdown note.
Type continuously.
Approximately every 2 seconds, the UI freezes for roughly 0.28 seconds.
Run Rebuild vault cache.
Typing becomes smooth while the rebuild is active.
As soon as the rebuild finishes, the recurring freezes return.
Comparison
A small local vault on the same machine remains smooth for 10+ minutes.
This suggests the issue scales with vault size / metadata volume rather than storage latency.
Ruled out during testing
The issue reproduces on a local NTFS SSD, so SMB/NAS/network latency is not required to reproduce it.
Syncthing folder paused: no improvement.
Syncthing completely shut down: no improvement.
Windows Search service stopped: no improvement.
Microsoft Defender exclusion for the complete local vault: no improvement.
File Recovery disabled: no improvement.
Obsidian installer updated from 1.9.14 to 1.13.7: no improvement.
A tiny vault using the same Obsidian installation remains completely smooth.
Expected behavior
Updating metadata for a changed note should not synchronously rescan property information for the entire vault on the renderer main thread after every autosave/cache-finished event.
Ideally, property information could be updated incrementally for affected files/properties, batched/debounced, or otherwise processed without blocking the renderer main thread.
This is particularly relevant for large-vault scalability: the current vault has approximately 10,000 files and is expected to grow substantially further.