Extension becomes unusably slow for bigger projects

[0xPhaze]

I've noticed a few times that when working in bigger projects, the plugin would just be too slow and not respond. I'm currently working on a personal project of mine, and just recently it suddenly got very slow. After writing a few more tests, the plugin stopped working completely, most notably, because I could not run the formatter anymore. I'm using forge as a formatter and can run forge fmt in the console without a problem. Changing the formatter also did not help. I was able to use it again after deleting the extension and some lines of code, but it quickly broke down again. If I can trigger this consistently, I'll share the repo.

My specs are:
Mac M2 Max 96GB

[0xPhaze]

Here is where it fails for me:
0xPhaze/solnum@c592785

Basically before the commit, everything seems to be fine, but as soon as I uncomment all that code, it starts getting very slow. From there - it depends on how long (sometimes almost instantly, sometimes after messing around a bit) - it eventually just freezes up entirely and I have to disable the extension.

I can delete the extension, and remove the code to reproduce this locally.

[kanej]

Here is where it fails for me: 0xPhaze/solnum@c592785

Basically before the commit, everything is fine, but as soon as I uncomment all that code, it begins getting very slow. From there it depends on how long (sometimes almost instantly, sometimes after messing around a lot; might depend on individual specs), but eventually it just freezes up entirely and I have to disable the extension.

Hey @0xPhaze, thanks for the reproduction, but the solnum repo appears to be private.

[0xPhaze]

Sorry, just noticed and it's public now

[kanej]

Brilliant, we will take a look. Reproduction repos make such a difference, thank you.

[antico5]

I tested on the given repo and given commit. I couldn't reproduce the freezing scenario. I benchmarked validation, analysis and formatting and it's all between 300 and 400 ms on my computer (i7-12650H, 16gb ram), on the biggest file (M32x32.sol, ~3000 LOC). I tried making several edits to see if it built up but no luck. What I can suggest is, when you notice the extension is being slow, please enable verbose logging, and then share the logs through a pastebin. The setting is "solidity-language-server.trace.server": "verbose",

[0xPhaze]

It starts out quite fast for me as well, but then gets to this state.. This is what I see on the language server output when it freezes.

[Trace - 7:21:39 PM] Sending request 'textDocument/formatting - (21)'.
Params: {
    "textDocument": {
        "uri": "file:///Users/lain/git/solidity/solnum/test/M32x32.t.sol"
    },
    "options": {
        "tabSize": 4,
        "insertSpaces": true
    }
}

I also get this window loading forever until I cancel it.

The file won't save, because the formatter or something seems to be stuck (but like I mentioned, there's no difference if I switch the formatter).

The language server itself still seems to be responding. This is the output when I hover. The above ^ window is still there.

[Trace - 7:23:35 PM] Sending request 'textDocument/hover - (22)'.
Params: {
    "textDocument": {
        "uri": "file:///Users/lain/git/solidity/solnum/test/M32x32.t.sol"
    },
    "position": {
        "line": 766,
        "character": 4
    }
}


[Trace - 7:23:35 PM] Sending notification '$/cancelRequest'.
Params: {
    "id": 22
}

Once I do actually cancel though, I get the following output:

[Trace - 7:25:23 PM] Sending notification '$/cancelRequest'.
Params: {
    "id": 21
}


[Trace - 7:25:23 PM] Sending notification 'textDocument/didChange'.
Params: {
    "textDocument": {
        "uri": "file:///Users/lain/git/solidity/solnum/test/M32x32.t.sol",
        "version": 9
    },
    "contentChanges": [
        {
            "range": {
                "start": {
                    "line": 0,
                    "character": 0
                },
                "end": {
                    "line": 0,
                    "character": 0
                }
            },
            "rangeLength": 1,
            "text": ""
        }
    ]
}


[Trace - 7:25:23 PM] Sending notification 'textDocument/didSave'.
Params: {
    "textDocument": {
        "uri": "file:///Users/lain/git/solidity/solnum/test/M32x32.t.sol"
    }
}


[Trace - 7:25:23 PM] Sending notification 'workspace/didChangeWatchedFiles'.
Params: {
    "changes": [
        {
            "uri": "file:///Users/lain/git/solidity/solnum/test/M32x32.t.sol",
            "type": 2
        }
    ]
}

Perhaps the issue is somewhere else? I switched back to Juan Blanco's extension and haven't had any problems at all in this repository.

Though it's also not just the formatting that is stuck. If I make obvious syntax mistakes, there is no feedback.

[kanej]

@antico5 taking a look at the foundry.toml there are file permission configurations:

Could there be a file permission error that blocks within the format call (which is execSync for forge), which then blocks other features? Could forge validation actually be the blocking aspect, but it shows up in the formatting call which is now server side?

[antico5]

What seems to be happening is that forge fmt is not exiting. Then our server is frozen because we are using execSync for calling it. We can't process other requests while we are waiting for that process. Not even cancelRequest requests.

I don't know why forge fmt could not be exiting properly. Perhaps it has to do with how we invoke it and how we send the standard input?

As a potential solution I could suggest switching to async exec for format calls.

[kanej]

@antico5 agreed. Are there any blocking calls to forge in validation?

@0xPhaze can you try turning the formatter to none? This will let us determine if it is just our formatter that has an issue or any use of the foundry cli within the extension in your context. When you get an example of it getting "stuck" are you able to run forge fmt and forge build?

[antico5]

@kanej no, only on the forge fmt call. the issue is that once it gets there, the whole node process is blocked until forge exits. I can replace it with an async exec and add a timeout, let me know if it works

[0xPhaze]

It's a bit hard for me to test, because this bug isn't easily reproducible. Though I remember that after it was stuck, changing the formatter setting to "none" or "prettier" didn't make a difference. I am still able to run forge fmt through the console once it's stuck.

[kanej]

Hey @0xPhaze, we released our changes to out forge support a few weeks ago. Are you still experiencing the same slow down issue, or can we close this issue?

[0xPhaze]

@kanej It seems to be working well so far. Thanks! Closing this issue.

[0xPhaze]

Hmm, just wanted to leave the note here that it's still quite slow at times. And it just took a few seconds until it displayed this new message when saving/formatting.

At least this time it did not freeze up entirely and I could continue using it afterwards.

[kanej]

Hmm, just wanted to leave the note here that it's still quite slow at times. And it just took a few seconds until it displayed this new message when saving/formatting.

At least this time it did not freeze up entirely and I could continue using it afterwards.

Thanks for the update @0xPhaze, what does the output show for those slowdowns?