I'm experimenting with pyright-langserver in a megarepo with more than 500k Python modules. I realize this is a bit of an unusual use case, so let me try to set
some context:

• The modules are loosely organized into logical groups, and these groups can arbitrarily depend on each other (all facilitated by buck)
• A typical developer only ever needs a small subset of these modules, but the subset can change very dynamically, and is normal to contain around a hundred or so of these logical groups
• The entire repo is not materialized onto disk, only the files needed for a particular task. This is achieved through a virtual filesystem

Our current approach to implementing some parts of the LSP involves jedi, which is designed to do static analysis in a "lazy" way: it only processes source files it definitely needs for a certain operation. This is great for the above environment because it generally doesn't do O(repo) operations unless you ask it to (say, by trying to find all references to a symbol).

the problem:
I noticed pyright-langserver's analyzer will immediately crawl all files in a workspace when it is registered and then every time the config is changed, which is unfortunate for two reasons:

• As far as I can tell the language server is unresponsive while crawling the directory hierarchy: it doesn't respond to incoming requests/notifications, and not even this error gets sent back to the LSP client
• It generates (in our case unnecessary) load on the system

potential solution:
Are there any plans to implement some kind of lazy analysis mode for the language server? There are several very useful LSP requests that could be served without even knowing all files in the workspace: textDocument/definition, textDocument/hover, textDocument/documentSymbol, etc.
This mode would be useful for smaller projects as well, because it could mitigate startup-time latency: go-to-definition could still return results while the entire project is still being processed.