Project fully re-indexes on each open

[MihaelIsaev]

Describe the bug
If I close a project and open it again, the extension starts indexing from scratch every time.
This is especially painful with large projects, like a Vapor project on an M1 Pro — indexing takes time and consumes significant CPU and battery.

To Reproduce
Steps to reproduce the behavior:

1. Open a Vapor project.
2. Wait for indexing to complete.
3. Close the project.
4. Reopen it and observe that indexing starts from scratch again.

Expected behavior
The extension shouldn't re-index the entire project every time it's opened. It would be great if it used some form of index caching.

Environment

• OS: Ubuntu 24.04
• Swift version (output of swift --version):

Swift version 6.1 (swift-6.1-RELEASE)
Target: aarch64-unknown-linux-gnu

• Visual Studio Code version: Version: 1.99.3
• vscode-swift version: 2.2.0

Additional info
Working inside VSCode devcontainer.

[matthewbastien]

SourceKit-LSP saves its index in .build/index-build/ and should be reloading it when the workspace opens. I can't seem to reproduce this issue with the dev container in SourceKit-LSP, anyway.

What does your devcontainer look like?

[MihaelIsaev]

Yeah, .build/index-build/ is definitely there, but it still seems to re-index from scratch every time.

I'd be grateful if you could take a look at my Vapor project — I’ve attached it.
Please open it in DevContainer mode.
I can consistently reproduce the re-indexing issue.

VaporAppInDevContainer.zip

[matthewbastien]

I tried out your dev container based on the swift-stream docker image and I can see that it's taking a very long time to index compared to using the nightly-6.1-jammy image from swiftlang/swift. I'm not sure why that would be at first glance, but perhaps you could try pointing at the nightly toolchain to see if the same issue occurs?

Since this is a docker container running Linux it might also be worthwhile to just use Swiftly to install a specific version of the Swift toolchain. It'll handle the system architecture for you rather than having to specify the download URL yourself. Instructions are on the installation page on swift.org: https://www.swift.org/install/linux/

[MihaelIsaev]

Thank you for taking the time to test it!

My image is based on Ubuntu 24.04 noble and uses the official Swift 6.1-RELEASE toolchain for it, built for the correct architecture (aarch64 for Apple Silicon), with all required system libraries installed. I'm not sure how Swiftly could install anything significantly different, and unfortunately I can’t use it anyway since I install the toolchains onto a dedicated volume to share it between devcontainers, so I need to stick with my setup.

I can see that it's taking a very long time to index compared to using the nightly-6.1-jammy image from swiftlang/swift
Perhaps you could try pointing at the nightly toolchain to see if the same issue occurs?

As suggested, I tested using the official swiftlang/swift:nightly-6.1-jammy image. Unfortunately, it shows the same behavior: very slow indexing and full re-indexing every time the project is reopened. I also see many errors in the SourceKit-LSP: Indexing output. I’ve attached a ready-to-test devcontainer project based on this image.

I also tried the swiftlang/swift:nightly-6.1-noble image, and the result was the same — very slow indexing with repeated full re-indexing and the same SourceKit-LSP errors. A test project based on this image is also attached.

Could you please take a look at these attached projects when you get a chance?
I’d appreciate any help identifying what might be causing slow indexing and full re-indexing.

VaporAppInDevContainerJammy.zip

VaporAppInDevContainerNoble.zip

[matthewbastien]

The SourceKit-LSP dev container has some extra configuration meant for improving performance. This is how I modified your container definition to get it to work for me. Can you try this out?

VaporAppInDevContainer.zip

[MihaelIsaev]

Thanks a lot, indexing is now feels 2× faster with the extra configuration. I’m guessing it’s thanks to this part:

"mounts": [
  // Use a named volume for the build products for optimal performance (https://code.visualstudio.com/remote/advancedcontainers/improve-performance#_use-a-targeted-named-volume)
  "source=${localWorkspaceFolderBasename}-build,target=${containerWorkspaceFolder}/.build,type=volume"
]

Really appreciate you pointing out this extra configuration requirement.

However, the original issue with re-indexing still persists. To reproduce it, you can simply wait for indexing to complete, then press Cmd+Shift+P and select Reload Window, after the reload, indexing starts again from scratch. This feels like it shouldn't happen, or at least should be significantly faster if nothing in the project has changed.

While this may be tolerable for small projects, it's a real issue for larger codebases. For example, we have a project roughly 3× larger than the Vapor codebase, and re-indexing it takes an extremely long time. In practice, it means we have to open the project once and avoid closing it for days, just to avoid the performance hit.

This also impacts common workflows, like switching between multiple projects throughout the day, where re-indexing kicks in each time, spiking CPU usage (e.g., M1 reaching 80C from idle 45C) and draining the battery noticeably.

SourceKit-LSP saves its index in .build/index-build/ and should be reloading it when the workspace opens.

Could this behavior be improved so that reopening a project uses the existing index more effectively? At the moment, there’s little to no difference between re-indexing and a full fresh index, which undermines the benefit of having a persistent index directory.

[matthewbastien]

Transferring to SourceKit-LSP as the issue is with background indexing.