0.26.2 hanging on link completion

[dstengle]

Describe the bug

My keyboard input hangs badly inside wikilinks and suggestions take forever to show up if they ever do.

Small Reproducible Example

No response

Steps to Reproduce the Bug or Issue

Start a wikilink by typing [[ and keyboard input hangs.

Expected behavior

Keyboard input with link suggestions without delays.

Screenshots or Videos

No response

Operating System Version

Ubuntu 24.04

Visual Studio Code Version

1.95.2

Additional context

No response

[riccardoferretti]

Thanks for reporting this, can you confirm that it doesn't happen in the previous version?
Would you be able to provide a reproducible example?

[mburleigh]

I've been seeing the same slowness since the last release (0.26.2) across multiple computers running Windows 11.

[riccardoferretti]

@mburleigh thanks for reporting - same request, can you please give us more detail? What is slow? Do you have a reproducible example?
I am not experiencing the problem, it would be great to have some instructions on how to see the problem

[mburleigh]

I'm seeing the same behavior as the OP. Typing in a note and hit "[[" to insert a wikilink and the input just hangs before the search text even renders.. Previously the would be used as a search string against the notes in my vault with very little delay and I could choose the note to link from the intellisense.

I just timed it and it took 9 seconds for the intellisense to appear.

[pderaaij]

Some questions:

• How large is your note collection?
• Any resources other than markdown files? For example, PDFs?
• Is there any message in the logs? See command: Developer: show logs.

[mburleigh]

6633 files in 388 folders
yes - PDFs, various image files, drawio files, even a couple of Polyglot notebooks, a geojson, probably a few others
nothing in the logs that I can see

[mburleigh]

tonight I'll clone the repo and see what I can see debugging
it felt like a regression bug to me but could definitely be related to my vault composistion

[dstengle]

BTW, if I revert to the previous release the problem goes away.

[pderaaij]

Yes. There is something off in the change I made. However, with the current information I can't understand what the problem is. Especially as I can't reproduce the problem. So, we need a lot of info to research

[dstengle]

The TrieMap is variable time based on size for lookup vs hashmap which should be fixed, so probably related to size of knowledge base?

[pderaaij]

@dstengle well. I think it happens in some circumstances. In your case, how large is your collection of notes. Especially, curious to the amount of folders you have. I am suspecting this might be an issue...

[dstengle]

I have ~2500 notes spread across ~600 directories (1 per day).

[jhhoward481]

I'm having the same problem described above.

System:

• Foam: 26.2 (bug does not happen on 26.1)
• macOS Sequoia 15.0.1
• 1700 files across 13 directories (about half are in the same directory as my VSCode workspace; the other half are in a single folder. The rest of the folders have very few notes). Mostly .md files, maybe 10 .jpeg and 10 .py files.
• Notes open in split view, about 50 currently open

Problem:

• Same as above as far as I know. Typing [[ and then a name of a note does not show possible auto-complete wiki link options. If I start typing a file name (e.g. "abcd"), then backspace, it freezes and I'm unable to edit the wiki link. I can move my cursor, but my keystrokes take a delay of many seconds before registering, sometimes even in another note if I move my cursor to another note before they register. I'm wondering if there's something wrong in how the search is performed or how the files are indexed.

[jhhoward481]

Just noticed one of my directories is a little deeper than the others: it's a small research git repo with some python files. No more than 30-ish subdirectories throughout at a max depth of around 6-7. Contains a few PDFs as well.

[pderaaij]

I've located the source of the problems. (cc @riccardoferretti)

In link-completion.provideCompletionItems we iterate over all resources. However, for each resource, we want to retrieve the identifier. We use FoamWorkspace.getIdentifier() for this. In this method, we also iterate over each resource to get the identifier. So, in larger collections of notes, this multiplies to a large set of iterations. This causes a delay in operations. This connects with the investigation I did for #1375 yesterday.

Will work on finding a solution for this.

[mburleigh]

Cartesian product strikes again! Thanks for proving we're not crazy @pderaaij !

[pderaaij]

Sorry about the regression. It was definitely an unexpected side-event. Although it helped me find a more general performance issue which I couldn't find up to now.

[mburleigh]

Tricky kind of bug to test for. Says a lot how quickly you were able to track down the root cause though - thanks!