Skip to content

⚡ perf(markdown): reduce memory used by large Markdown inputs - #2710

Merged
harehare merged 2 commits into
mainfrom
perf/reduce-markdown-memory
Oct 27, 2026
Merged

harehare merged 2 commits into
mainfrom
perf/reduce-markdown-memory

Conversation

@harehare

Copy link
Copy Markdown
Owner

Summary

Type of Change

  • 🐛 Bug fix
  • ✨ New feature
  • ♻️ Refactor
  • 📝 Documentation
  • ⚡ Performance
  • ✅ Test
  • 📦 Build / dependencies
  • 👷 CI

Checklist

  • I ran cargo fmt and cargo clippy and addressed any warnings
  • I ran just test-all and all tests pass
  • I added or updated tests covering this change
  • I updated relevant documentation (/docs, crate README.md) if needed

Additional Context

`Option<Position>` shrinks from 40 to 20 bytes, which lowers the size of every
node. On a 19.6MB document the peak RSS of `nodes | len` goes from 681MB to
601MB.

`Point.line` and `Point.column` are public, so this changes the API of
mq-markdown. Parser internals keep `usize` and saturate to `u32::MAX` where a
`Point` is built. mq-ffi no longer needs its own saturating conversion.
A `Vec` starts at four elements, so a container with one child held room for
four blocks. Nested block vectors are now shrunk once they are complete, which
takes the block tree from 267MB to 196MB on a 19.6MB document.

`resolve` also copied the whole root vector when appending it into the empty
output. It now takes the vector and shrinks it, which lowers the peak during
resolution from 506MB to 380MB. Peak RSS of `nodes | len` goes from 681MB to
532MB overall, and the run is about 10% faster.
@harehare
harehare merged commit 5dd02ab into main Oct 27, 2026
13 checks passed
@harehare
harehare deleted the perf/reduce-markdown-memory branch October 27, 2026 13:18
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