Jump to definition consumes the entire CPU capacity

[lgraziani2712]

Specs:

• Windows 10.
• Atom 1.19.0-beta3
• Hyperclick 0.1.2
• flow-ide 1.6.0

Description

Everytime I try to jump to a definition, this happens:

And my PC freezes. The WMI Provider Host and those bunch of nodejs instances only appear when I try to jump to a definition.

While you try to stabilize this functionality, can you add an option to disable it? Right now I cannot use flow-ide because of that (or I need to be careful not to try to jump to a definition.)

Thank you for your work :)

[steelbrain]

You can disable the hyperclick package to disable jump to definition. You are on windows and Flow on windows was still experimental the last time I checked. Flow architecture has a server that runs in the background and scans the entire project into memory and then clients that query that server. If I am guessing correctly the server is not yet supported on windows and every client tries to scan the entire project by themselves.

Either way, nothing we can do in this package, Flow maintainers will have to fix this in flow :)

[lgraziani2712]

It has a server on windows. And if I'm not wrong, it scans the entire project on init.

[steelbrain]

Regardless, if it jammed the editor, then it would be flow-ide's fault, if it spawns processes and those processes jam the OS then it's those processes' fault.

You could try submitting debug information to the flow repository, people there might be able to help you debug the root cause of this

[lgraziani2712]

What debug information?

How can I generate that information?

Thank you!

[steelbrain]

No idea 😅 The maintainers of flow would know tho

[lgraziani2712]

They told me "The flow binary will show up in windows as flow.exe. This is not a flow issue, it seems as though it is an issue with the plugin you're using."

🙈

[steelbrain]

So next step in debugging, install Process Explorer and try to get the command line arguments of the spawned Node processes that take up all of that CPU

[lgraziani2712]

Wow! I didn't knew about that tool. So good!

The command line is:

node "C:\dev\repos\codimo\node_modules\.bin\\..\flow-bin\cli.js" "get-def" "--json" "C:\dev\repos\codimo\core\blockly\executorGenerator\index.js" "33" "3"

Here is a screenshot

Every process has the same command line.

[Arcanemagus]

Is your project's flow-bin dependency up to date?
Is Node.js up to date?

Normally the Node.js wrapper script should determine the proper flow binary to run, spawn that, and exit itself. For some reason on your machine the wrapper script is never exiting.

In any case, this is an issue with either flow-bin or flow themselves. Check that you are on the latest versions of flow-bin and node first.

[lgraziani2712]

Uhmm, they exit. But spawn a lot of them, more than 20.

Previous versions:

• Node v8.0.0
• flow-bin: v0.50.0

Actual versions:

• Node v8.2.1
• flow-bin: v0.51.0

Still happens. By the way, testing it now, I found that the more time I put the mouse over an element pressing the key to jump to a definition, the more processes spawn.

[steelbrain]

That would only happen if you hold ctrl all the time, do you?

[lgraziani2712]

Uhmm, yes i think. It happens only if I hold ctrl, but the more I hold it, the more processes will be.

[steelbrain]

We could cache the results if the contents of the editors have not changed since the last time you held ctrl, could you open an issue on steelbrain/intentions for this please? I think we could fix it there

[lgraziani2712]

I updated to the new version, but still having the issue.

[steelbrain]

🤦 I forgot this package uses Hyperclick not intentions. Best bet? Disable the hyperclick package. We would no longer spawn processes to get jump to definition info

[lgraziani2712]

I think I can confirm this is a hyperclick bug. I tried Nuclide, and occurs the same problem.

[steelbrain]

Closing in favor of #105

[leos]

A flow client does spin up for every control hover, but the overhead should be pretty low and they should ping the server (which should be running) and die pretty quickly. Unless you're ctrl+hovering over hundreds of words in a few seconds. We probably should be invoking flow.exe rather than node.exe on windows - I'll try this out on a windows test machine to see what's going on.

Meanwhile, @lgraziani2712 - what happens on your machine if you run that command from the command line (in the appropriate directory)? and then when you run it again?

Do you get a warning about Flow restarting the running server because the versions don't match up? If not, does the command run pretty instantly? or how long does it take to run or is there any other warning/console output that might indicate why its running slowly?

[leos]

@lgraziani2712 - can you look at the settings for flow-ide, what is your flow-ide.executablePath set to, if anything?

[lgraziani2712]

Is empty.

[leos]

Ok, the root issue is that we're not invoking flow.exe on windows. @lgraziani2712 if you need a workaround for now, you can set flow-ide.executablePath to the location of flow.exe (typically it's either in a global location or in node_modules\flow-bin\flow-win64-<VERSION>\flow.exe. Try that and see if it works.

I'll see if I can get a good answer out of the Flow folks about the best way to discover its location.

[lgraziani2712]

Sorry @leos didn't saw your first comment!

what happens on your machine if you run that command from the command line (in the appropriate directory)? and then when you run it again?

I updated that file, so I ran the following one:

node "node_modules\.bin\\..\flow-bin\cli.js" "get-def" "--json" "core\blockly\parseInstructions.js" "29" "3"

It always returns:

{"path":"C:\\dev\\repos\\codimo\\core\\blockly\\parseInstructions.js","line":26,"endline":26,"start":9,"end":20}

Do you get a warning about Flow restarting the running server because the versions don't match up? If not, does the command run pretty instantly? or how long does it take to run or is there any other warning/console output that might indicate why its running slowly?

1. No, I don't get a warning.
2. Yes, it runs pretty instantly.

[leos]

No problem. Try setting the executablePath and let me know if that helps. There's a chance it may not because of another code issue :-/

[lgraziani2712]

I tried updating the executablePath as you said, and then I enabled hyperclick, but still spawns a lot of processes.

[leos]

And they're still node.exe, right?

[lgraziani2712]

Yes.

[lloiser]

I think I have found at least one cause: on windows the hyperclick provider is called even if the mouse stands still. This is not the case for mac (I haven't tried it on linux yet)
I tried to capture it in a gif:

So move the mouse over any function and just keep the "trigger keys" of hyperclick pressed. As you can see the hyperclick provider is called continuously!
Now image calling flow 54 times within 4 seconds! It's not surprising that this slows down your computers!

I will open an issue somewhere in hyperclick / atom-ide-ui / nuclide

[leos]

Ouch. That's really frustrating. Nice find @lloiser.

The readme for that repo says to file issues in facebook/nuclide. Maybe file it there instead?