Obsidian version: 1.13.4 (Linux snap, latest/stable track)
OS: Ubuntu (GNOME, Wayland), AMD laptop CPU
Summary
Having a plain-text note of ~7,000-13,000 lines (1.6-2 MB, pasted raw log dump, zero markdown syntax — no links, no headers, no code fences) anywhere in a vault causes the renderer process to peg at ~100% CPU continuously, with heavy memmove/page-fault activity, even if the file is never opened in an editor tab.
Steps to reproduce
- Create a new empty vault. CPU stays idle (~1%) as expected.
- Copy a single large plain-text note (~2 MB, 7,000+ lines, no markdown syntax) into the vault folder.
- Within seconds, without opening the file in any editor tab, the renderer process CPU usage climbs to 90-100%+ and stays there continuously.
Confirmed independent of:
- The “Search” core plugin (reproduced with it explicitly disabled)
- Any open editor tab (reproduced with zero tabs open on the file)
- The Graph view (never opened)
- Community plugins (none installed)
- IndexedDB/search cache state (reproduced after wiping
~/.config/obsidian/IndexedDB) - Vault-level settings/workspace state (reproduced with a freshly copied
.obsidian/config, isolated from the rest of the vault content)
Diagnostic data (perf profile)
perf record -g on the renderer during the high-CPU period shows 98.75% of the DedicatedWorker thread’s time in a single call chain:
v8::Function::Call
→ ... → __memmove_avx512_unaligned_erms (self 9.95%, cumulative 76.56%)
→ asm_exc_page_fault → do_anonymous_page → alloc_anon_folio
→ clear_page_erms (self 11.69%)
i.e. the worker repeatedly allocates and fully copies large chunks of freshly-touched (never-before-accessed) anonymous memory — not a normal GC pass, not disk I/O (iostat showed near-zero device activity throughout), and not GPU compositing (GPU busy ~2%). strace -c -f on the same process showed 78% of time in futex and ~45,000 combined madvise/mprotect calls in a few seconds — consistent with heavy inter-thread contention around this allocation/copy pattern.
Expected behavior
Metadata/link scanning of a large plain-text file with no markdown syntax to parse should be fast and should not require repeated full-buffer reallocation, and should definitely not run this expensively for a file that is never opened.
Related reports (checked, not exact duplicates)
- When md files with a large number of local links are saved, the index will be performed for a long time each time — traced by a moderator to notes with many underscores, not link count itself. My case has zero links and is triggered by mere file presence, not by a save action.
- Parsing complex notes causes 100% CPU and eventually causes all notes to be lost — triggered by many unescaped
</>characters, legacy editor only (maintainers declined to fix for that reason). My case has no</>density and reproduces regardless of never opening the file.
Flagging these because the underlying theme (large/dense plain-text notes causing pathological CPU in whatever system parses them — legacy editor, link resolver, or here the background metadata scan) seems to recur across different specific triggers, which might point to a shared underlying weakness worth looking at holistically.
Additional notes
Happy to provide the full perf.data/strace output if useful — this was captured on a real, reproducible case (not a one-off), and the pattern is 100% reproducible by just placing the file in any vault.