-
Notifications
You must be signed in to change notification settings - Fork 112
Extension seems to make too many simultaneous requests to Flow server, cratering performance #414
Comments
Did you manage to alleviate your problem? I'm facing such a horrible performance I can't really work... |
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. |
I ended up downgrading to version 1.9.2. |
@ospfranco I currently use a personal fork of |
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: |
@ospfranco I definitely saw different behavior between this extension and my fork of |
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. |
@ospfranco You're saying that "overwhelms the Flow server with way too many requests" is the intended behavior of |
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. |
also, what version of Flow are y'all using? we've invested heavily in IDE performance over the last 6 months. some notable ones: |
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:
Does this extension throttle requests to the server at all?
I forked and cleaned up the
vscode-flow-ide
extension before switching back toflow-for-vscode
, since it supports LSP and lazy mode. One of the things I did invscode-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 withflow-for-vscode
. Maybe at some point I should just dig through the code here looking for improvements I could make...The text was updated successfully, but these errors were encountered: