Language server indexing very slow inside a devcontainer

[markkirchner]

I have a dev container setup for an app consisting of multiple docker containers (=> .devcontainer.json points to a docker-compose.yml) running on a Windows host using the WSL2 backend. The various source code folders for the different containers have been checked out inside WSL (=> not on the Windows FS) and are bind-mounted from there into the containers.

When opening the dev container in vscode, the language server starts indexing the contents of those folders as expected. But for unknown reasons, this takes a huge amount of time - 10 to 15 minutes. During that time, code-completion is unavailable (or maybe only partially available). Total amount of data is around 1.8 GB, but obviously not all of that is PHP code.

Output looks like this while it "hangs":

As far as I can tell, CPU-/RAM-/FS-load during the time this happens is negligible. Also, the machine this thing runs on is fairly powerful, this should not be an issue.

After about 12 minutes (in this case) it continued:

A few seconds after that, indexing stops and code-completion works as expected.

When doing the same thing outside of the dev container in WSL, indexing (which actually has to process even more files/data in this scenario) just takes about 30 seconds.

[jakubmisek]

The [3:14:39] timestamp indicated, that it just loaded packages, maybe because they changed, or composer.json changed. It does not mean that indexing was running in the meantime.

Do you see "Indexing ..." in the status bar all the time?

[markkirchner]

Yes, "Indexing ..." (plus the spinning icon in front of it) is there all the time. It only disappears shortly after the 12 minute gap.

[markkirchner]

And as an update: I have the suspicion that a certain part of the filesystem (a data directory that is mounted into the containers via SSHFS) might be causing the problems. This directory does not contain any PHP-code but consists of a huge and deeply nested structure which (being on SSHFS) is probably very expensive to fully traverse.

So: Is there a way to tell the indexing process to completely ignore a certain directory and everything below? So that it does not even try to decend into the tree?

I've already tried using the vscode settings files.exclude , files.watcherExclude, search.exclude and php.problems.exclude. None of them seem to make any difference (regading the indexing).

[jakubmisek]

Thank you for the update. We'll need to setup a similar environment and start testing it.

files.exclude is respected. (Specifying simple paths without asterisks works best.) Files and directories in there are not enumerated during indexing. You may need to reload the window when changing this setting if Indexing is in progress.

I may add a more detailed logging, if the process takes suspiciously more time.

[markkirchner]

Ok, I'll try it again with files.exclude, making sure not to include any asterisks.

I may add a more detailed logging, if the process takes suspiciously more time.

That would probably help a great deal in tracking down the problem, thanks.

[markkirchner]

Ok, I was successful using files.exclude now: Indexing time is down to a few seconds.

The only thing that was a bit tricky: The paths have to be "really simple" - even a trailing "/" is too much. While vscode itself accepts such entries perfectly fine (=> the directory disappears from the "explorer" view), the language server still seems to process them in this case. Maybe this could be handled in a bit more permissive way?

But in any case, I guess the current issue can be closed. Thanks for the help!

[jakubmisek]

Thank you very much for your feedback and for trying the files.exclude!

May I ask what was causing the problem? I'd like to make it work properly for anyone with the same issue.

Also I'll take a look at the file patterns.

[markkirchner]

May I ask what was causing the problem?

As suspected, a deeply-nested directory structure mounted into the containers as an SSHFS volume (-> via a non-local network connection) was causing the slowdown. After excluding that directory, the problem went away.

I don't know for sure, but I would guess that this "SSHFS volume"-stuff is probably a fairly exotic setup that we are running here... 😅

[Miloslav]

Hello Mark,

We're trying to replicate this to test it out and be better prepared for such a setup.

May I ask more information about your configuration? Any details would help. e.g. do you use Vieux/sshfs docker volume?

Thanks

[markkirchner]

Hi Miloslav,

yes, we're using vieux/sshfs. Configuration is pretty much default, I guess - the allow_other and reconnect options are set.

The SSH connection is tunneled through a VPN. (But doing SSH directly - without the VPN - did not make any difference in my tests.) The network connection is typically consumer-grade DSL on one end and high-end fiber on the other side (=> bandwidth should not be much of a problem). Ping is typically somewhere between 15 and 30 ms.

Some stats about the filesystem tree that is mounted in: ~100,000 files spread over ~30,000 directories with a total amount of data of ~7 GB. The maximum nesting depth of the directory structure is 12 levels deep with an average depth of ~3.5 levels.

HTH, Mark