Skip to content

perf: add reverse index to EmbedsRepository to avoid full-map iteration#544

Open
yoshi-taka wants to merge 1 commit into
scambier:masterfrom
yoshi-taka:embeds-reverse-index
Open

perf: add reverse index to EmbedsRepository to avoid full-map iteration#544
yoshi-taka wants to merge 1 commit into
scambier:masterfrom
yoshi-taka:embeds-reverse-index

Conversation

@yoshi-taka

Copy link
Copy Markdown

refreshEmbedsForNote() previously iterated the entire embeds map to find entries referencing a specific note. Add a derived noteEmbeds reverse index (notePath -> Set) so refresh only touches embeds previously referenced by the affected note instead of scanning all embed entries.

embeds remains the source of truth. noteEmbeds is an in-memory derived index and is not persisted to cache. It is rebuilt from embeds during cache load via addEmbed(), and rebuildNoteEmbeds() is also called after renameFile() to reduce consistency risk, since renameFile() updates embeds directly but does not maintain the reverse index incrementally.

This adds some memory overhead and introduces a second in-memory index, but keeps the consistency model simple and avoids stale persisted state.

refreshEmbedsForNote() previously iterated the entire embeds map (O(n))
to find entries referencing a specific note. Add a noteEmbeds reverse
index (notePath -> Set<embeddedPath>) for O(k) lookup where k is the
number of embeds in the affected note.

noteEmbeds is a derived index rebuilt from the source-of-truth embeds
map. It is not persisted to cache. rebuildNoteEmbeds() is called after
renameFile() to keep the index consistent, since renameFile() updates
embeds directly but does not update noteEmbeds incrementally.
@scambier

Copy link
Copy Markdown
Owner

Hello and thanks for your PR.

I'm just not sure that the potential performance gain is worth the added complexity

@yoshi-taka

Copy link
Copy Markdown
Author

Thanks, that makes sense.

I agree this may not be worth the extra bookkeeping unless this path is actually hot in real-world vaults.

The case I had in mind was a large vault with many embeds, where refreshing embeds for a single note repeatedly ends up scanning the global embed list. If users ever report slow refresh/reindex behavior in embed-heavy vaults, this reverse index might be worth revisiting.

Happy to leave it as a future optimization rather than adding complexity now.

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.

2 participants