Extension seems to make too many simultaneous requests to Flow server, cratering performance

[jedwards1211]

I've been using the extension in LSP, non-lazy mode with Flow 0.131.0, and when I'm jumping between files and saving changes multiple times before the Flow server finishes rechecking, I see the following symptoms:

• Flow status in the status bar rapidly flickers between "starting up" and "finishing up" for several seconds
• Sometimes in the problems panel I see identifier names appearing one character at a time, as if they're being typed out slowly. And in an editor I can also see the error underline gradually extending under an identifier one character at a time.

Does this extension throttle requests to the server at all?

I forked and cleaned up the vscode-flow-ide extension before switching back to flow-for-vscode, since it supports LSP and lazy mode. One of the things I did in vscode-flow-ide to fix performance problems was throttle requests to the server so that only one was in flight at a time. That probably isn't ideal since jump to definition, hover inspection, etc. are all blocked while the server is rechecking, but it does seem to finish rechecking faster. I get the impression that this extension is making too many simultaneous requests to the server while it's rechecking, bogging it down severely.

I tried my fork of vscode-flow-ide again and I can definitely attest that rechecking finishes up faster than with flow-for-vscode. Maybe at some point I should just dig through the code here looking for improvements I could make...

[ospfranco]

Did you manage to alleviate your problem? I'm facing such a horrible performance I can't really work...

[adelespinasse]

This is suddenly happening to me, and I don't think I changed anything. I used to have it set to only run Flow when I saved files. Now that option doesn't seem to exist anymore. I'd really like to go back to how it worked before.

[adelespinasse]

I ended up downgrading to version 1.9.2.

[jedwards1211]

@ospfranco I currently use a personal fork of vscode-flow-ide that isn't perfect but at least avoids this kind of problem.

[ospfranco]

As it turns out flow didn't do "anything" wrong. Unfortunately depending on your import structure excessive file checking might occur. Here is how I tried to debug my problem:

https://ospfranco.com/post/2021/08/25/how-to-visualize-flowtype-dependency-tree/

One possible mitigation is enabling types-first mode:

https://flow.org/en/docs/lang/types-first/#:~:text=In%20types%2Dfirst%2C%20Flow%20extracts,It%20improves%20error%20reliability.

[jedwards1211]

@ospfranco I definitely saw different behavior between this extension and my fork of vscode-flow-ide in the same project, so I doubt it's a matter of import structure...it also wasn't really Flow's fault, but rather this extension's fault for seemingly making too many simultaneous requests

[ospfranco]

Sorry to say, that is the intended behavior. So my point remains valid there is nothing "wrong" per se with flow and the extension.

It is frustrating when the type-checking process is slow indeed, that's why I shared how I made sure it was no bug. And also shared the mitigation I went with. Types-first made the type checking around 50% - 80% faster in my case.

I was also trying to answer the latest comment left by Adele. Just sharing solutions.

[adelespinasse]

@ospfranco You're saying that "overwhelms the Flow server with way too many requests" is the intended behavior of flow-for-vscode?

[mroch]

version 2.0 of this extension removed the legacy non-LSP integration. the LSP integration was already the default in 1.9.2. @adelespinasse, did downgrading alone help or did you also disable the LSP?

this extension doesn't generate any requests. it just sends the requests that VSCode generates. VSCode generates a lot of requests -- hovers as you move the mouse, documentHighlight every time you move the caret, change events and completions on every keystroke, documentSymbol (for the outline pane), etc. etc. etc.

the server queues all these requests and responds to them serially as fast as it can, so the parallelism ("simultaneous requests") is not an issue, but the requests can stack up and queue. on every change event, it parses the whole file to send "live" parse errors, and locally typechecks it to find type errors within that file (it only checks dependents when you save). if the file takes a long time to parse (is it huge?) or typecheck (very rare, but possible -- something like 0.01% of files at Facebook are super slow) it can make things back up.

i'd be curious to see the timing of the requests. set the "Flow > Server > Trace" vscode setting to "verbose" ("messages" might work but can't recall) and then check the Output pane. the contents of the requests and responses isn't really important and likely includes snippets of your code so don't need to share that.

[mroch]

also, what version of Flow are y'all using? we've invested heavily in IDE performance over the last 6 months.

some notable ones:

• 0.172.0: Improve performance of IDE commands when Flow is busy typechecking
• 0.164.0: Changed scheduling of LSP commands in parallel with typechecking, to prioritize commands.
• 0.161.0: Significantly improved overall performance.