Wiki link autocomplete cannot do fuzzy search in large vault

Bug reports
,
1

Updates

2023/10/14

It seems clear to me now that 10000 searchable items will cause this behavior (according to White noise and my testing.)
This includes files (attachments included), broken links and aliases.
For further information, see Options to control the Quick Switcher algorithm above 10’000 files - Feature requests - Obsidian Forum

2023/10/9

I deleted some useless files, and the problem went away (for now).
My current file count is 7538, with 661 broken links.

Steps to reproduce

  1. Start a large vault
    (My vault has 7700+ files, about half of them images. Total size is 2.13 GB)
    (Also reproduced in sandbox vault by adding10k files, 4.2 GB)
  2. create a file called “test 123” (with a space)
  3. type “[[test12” within the file (with no space)

(I didn’t just do this for the sake of stress testing. All the files are my real notes, created in roughly 1 year. So this is causing real trouble for me)

Did you follow the troubleshooting guide? [Y/N]

Yes

Expected result

Wiki link autocomplete should find the file.

Actual result

Instead, “no match found” is shown.

Environment

SYSTEM INFO:
Obsidian version: v1.4.14
Installer version: v1.4.12
Operating system: Windows 10 Home 10.0.22621
Login status: logged in
Catalyst license: none
Insider build toggle: off
Live preview: on
Legacy editor: off
Base theme: dark
Community theme: none
Snippets enabled: 0
Restricted mode: on

RECOMMENDATIONS:
none

Additional information

image
image2560×1375 105 KB

I did find a similar report, but it’s not submitted in the bug category:
Fuzzy-Search-Autocompletion of Wiki-Links fails if spaces are involved - Help - Obsidian Forum

A similar Feature request concerning quick switcher:
Options to control the Quick Switcher algorithm above 10’000 files - Feature requests - Obsidian Forum

2

This isn’t a bug, it’s a performance optimization.

There’s a request to allow fuzzy search on larger vaults.

1 Like
3

Thanks @Alicila for linking my forum post and thanks @CawlinTeffid for pointing to the Feature Request (I would like to double the request for such a switch!!).

I’d like to ask for some clarification on the algorithm’s spec… and maybe we are not talking about the same thing here: So both, @Alicila and me are talking about the Wiki-link autocomplete (which is not the same thing as the Quick Switcher) and both of us also have significantly less than 10’000 notes (Alicila writes they have ca. 7700+ files (including attachments) and I have even less: ca. 3600+ files plus ca. 700+ attachments).

@Alicila : how is QuickSwitcher behaving in your case? In my case it still works (and importantly: without any performance issues!!). Just the Wiki-Link Modal is behaving differently, which I really don’t understand why.

From the information given, I’m deducing that there are not one but two “performance optimizations” in place, one for QuickSwitcher and one for Wiki-Links Modals, however, with different thresholds… May somebody of the mods/devs check this hypothesis?

1 Like
4

I’d expect autocomplete and quick switcher to use the same algorithm, but I don’t know for sure. Since you’re seeing different behavior I’m moving the thread back out of the graveyard.

(I saw the simpler algorithm in quick switcher for a while when I had ~7,700 notes too — not sure why, and it’s no longer true.)

1 Like
5

Thanks @CawlinTeffid. Btw.: I’ve just posted to the linked Feature Request, with some arguments why there should be more proactive information about the existence and behavior of the algorithm.

6

I have a large vault. I have many notes with filenames with spaces in them. I use the Various Complements plugin. I can set trigger for 2 or 3 words in Vault Complement and not remember not getting a find. On the plus side, no need to start with [[, either. Give it a shot, if you like the sound of all this.
I use it for custom dictionaries as well.

7

Quick switcher (and Quick switcher++ plugin) behaves normally, with fuzzy search, without any performance issue. I believe this means that fuzzy search is feasible at current vault size.

1 Like
8

It’s 10000 searchable items, that includes notes, attachments and other files in you have that enabled.

9

But how is quick switcher working fine at this size? (Which demonstrates that, potentially, wiki link can work fine too?)

10

It all depends on how fast your computer is.

11

It’s 10000 searchable items

Thanks @WhiteNoise. May you elaborate a bit further on “searchable items”: How about wiki-links to non-existing notes? How about aliases? Do they all count, too?

Is this documented somewhere? Moreover, for a standard user without coding-skills, I believe there is no way to get a rough estimate on how many “searchable items” there are in their vault… and hence no information to deduce how far they are from the 10k limit.

12

I don’t understand this (and here I’m just doubling what @Alicila has already brought into the discussion): On my computer quick switcher is very fast and accurate in performing fuzzy searches. However, the wiki-link autocomplete modals are not. How should this be just due to computer power rather than due to a difference in the search algorithms?

Are the algorithms open source? If not, it would still be important to know: Are the search algorithms qualitatively dependent on computer speed or not? Or in other words: Would they deliver the same results on every machine (if you want, say, after waiting for 5 seconds)?

To underline the urgency of our request: It is not about the time it takes for the algorithm to dump the results. Much more it is about reliability. We need to know, whether the note we are expecting to retrieve via wiki-link-autocomplete does or does not exist. Otherwise, this will quickly end up in lots of notes with similar names. This is especially true, since the “optimised” algorithm is sensitive to spaces and dashes.

1 Like