0.26.2 hanging on link completion

dstengle commented 2 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

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

riccardoferretti commented 2 weeks ago

@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 commented 2 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

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

pderaaij commented 2 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

@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 commented 2 weeks ago

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

jhhoward481 commented 2 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

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

pderaaij commented 2 weeks ago

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 commented 2 weeks ago

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

foambubble / foam