seems a process is blocking some frontend actions

[gsmachado]

It seems that in the block explorer there's a process blocking some actions... like: sometimes when I click on a block, it takes a while until it appears something...

I think the indexing process is blocking some frontend actions, somehow. It's not perceptible on fast machines (or when you're not utilizing a lot of CPU).... but if you try on an overloaded system, you can feel it, and it's bad. 😄

I tried to show it in the following gif, but the exact moment when I click on the block is (unfortunately) not visible. But maybe you can realize that I clicked on block 6, then moved the mouse a bit down, waited some secs, then when I was going to click again the block 6 box suddenly appeared.

[djnicholson]

I suspect this may manifest more on machines that are IO constrained. There are a few places where I need to read small files from disk within the main extension process and have lazily used sync reads.

The extension and the panels both have their own single-threaded JS process and they communicate by posting messages between each other. I believe that the UI is posting messages to the extension at a time when it is blocked synchronously reading a file, when it is done it will post a message back (causing the panel to update) but it could be multiple seconds after the event triggering the update when IO constrained.

Will make all file IO async...

[gsmachado]

I suspect this may manifest more on machines that are IO constrained. There are a few places where I need to read small files from disk within the main extension process and have lazily used sync reads.

yeah, that sounds like a really good guess on where to start... 😄

Will make all file IO async...

alright... I can try to test it once a new version is out. 👍

[djnicholson]

alright... I can try to test it once a new version is out. 👍

@gsmachado can you give this one a whirl? https://github.com/ngdenterprise/neo3-visual-tracker/releases/tag/v0.0-master (built at 95074d0)

It has most of the synchronous file IO removed (there are a few remaining that are architecturally harder to remove, but also not in any background code paths).

If you are still seeing issues, a Performance trace from the Chrome dev tools within VS Code would be useful (let me know if you need further instructions for generating this).

[gsmachado]

Ok, some feedback after some testing: I tried to test in docker containers (with constrained IO, which I can set some policies), and yes, it's better. However, I can still feel a small delay in some actions (that the UI becomes irresponsive for a fraction of a second), mainly in the block explorer part.

However, to be honest, it's good for now. 🎉 💪

If I were you, I would keep the task to remove the few remaining synchronous file IO calls in the backlog, just in case. 😄

I will close the issue now. Looking forward to a release with that fix. 💯