Are you lacking performance in some particular way? I’m thinking it could be Calva. It is a bit slow on large Clojure files. I don’t think language extensions interfere much. They mostly work on “their own” files. For Clojure development I use Calva only.

Not only a bit slow, but also, it seems, VS Code sometimes lets fresh keystrokes interfere with Calva's tidying-up, resulting in imbalanced parens that Paredit would not normally permit. For example, I had to learn not to let the Delete key auto-repeat. Does Calva benefit from the addition of more "CPUs" when operating in a virtual guest?

I'm not sure if it's calva, I disabled all but like 4 plugins and things are better now so far

i was experiencing extreme keyboard input lag (I have a mac studio)

What git extension do you guys use? I am trying Codelens but am finding it misses key things like an easy history view and is otherwise bloated

I use Gitlens. Takes some disabling of things to fit my liking, but once that’s done it’s fantastic.

Extreme keyboard input lag is known to have happened in Calva, but when it happens it is due to something with the file so not fixable via any other mean than figuring out what about the file trips Calva up. We have fixed all known issues so far, but there can be more lurking of course.

Doesn’t sound like tuning VS Code performance helps against such a problem anyway. It could have been one of your extensions. There is a feature for bisecting extension problems. I think you find it in the top meatballs menu of the extension pane.

ok, thanks

I'm pretty sure VS Code utilizes some degree of multi-core processing. So regardless of what Calva does in this regard, you would still theoretically benefit from more cores by giving VS Code better opportunity to get out Calva's way.

One meaningful perf suggestion I can offer is to disable Calva's Rainbow Brackets and enable editor.bracketPairColorization.enabled instead. Microsoft built that in specifically because it is impossible for an extension to implement some much needed performance improvements. https://code.visualstudio.com/blogs/2021/09/29/bracket-pair-colorization

I think that will gain zero performance for keyboard input. Especially for Dustin who has both disabled. 😀 But generally it only makes sense to switch for performance reasons if you experience lag with rainbow painting. Never heard reports about such lags outside .edn files. And you need to be ready to sacrifice Calva’s Clojure aware brackets for the general ones. I also doubt that that bracket painting performance is out of reach for extensions. They published their algorithm. It’s more a matter of priorities.

• That suggestion was targeted at OP, not the keystroke complaint. • No reports of lag doesn't necessarily mean there is none, just that there is not enough to stand out. Lag is cumulative. So, when specifically tuning for perf, it makes sense to not ignore things just because you aren't consciously aware of them in isolation (especially when you don't have very many other knobs you can turn instead). • What do "Clojure aware brackets" add? • The algorithm is not enough. The extension APIs do not provide the necessary facilities. > Unfortunately, the non-incremental nature of the Decoration API and missing access to VS Code's token information causes the Bracket Pair Colorizer extension to be slow on large files: when inserting a single bracket at the beginning of the checker.ts file of the TypeScript project, which has more than 42k lines of code, it takes about 10 seconds until the colors of all bracket pairs update. During these 10 seconds of processing, the extension host process burns at 100% CPU and all features that are powered by extensions, such as auto-completion or diagnostics, stop functioning. Luckily, VS Code's architecture ensures that the UI remains responsive and documents can still be saved to disk. > > CoenraadS was aware of this performance issue and spent a great amount of effort on increasing speed and accuracy in version 2 of the extension, by reusing the token and bracket parsing engine from VS Code. However, VS Code's API and extension architecture was not designed to allow for high performance bracket pair colorization when hundreds of thousands of bracket pairs are involved. Thus, even in Bracket Pair Colorizer 2, it takes some time until the colors reflect the new nesting levels after inserting { at the beginning of the file: > > While we would have loved to just improve the performance of the extension (which certainly would have required introducing more advanced APIs, optimized for high-performance scenarios), the asynchronous communication between the renderer and the extension-host severely limits how fast bracket pair colorization can be when implemented as an extension. This limit cannot be overcome. In particular, bracket pair colors should not be requested asynchronously as soon as they appear in the viewport, as this would have caused visible flickering when scrolling through large files. A discussion of this can be found in issue #128465. > > Instead, in the 1.60 update, we reimplemented the extension in the core of VS Code and brought this time down to less than a millisecond - in this particular example, that is more than 10,000 times faster.

That’s only if you colorize all brackets. Calva only colorized those in view. There is very little performance to gain there. You speak with authority about things you know very little about, @U90R0EPHA

> And you need to be ready to sacrifice Calva’s Clojure aware brackets for the general ones. what's this?

It’s mostly about that Calva will colorize and highlight brackets together with any reader tags going with the form.

Are you saying I need to leave these turned on? I'm a bit confused

So then you are constantly monitoring the viewport for changes and repainting? That would certainly amortize the cost, though in many cases the total cost might be even higher. You still need to read out-of-view code if the colors are to stay accurate. So, I guess you are trading raw performance for perceived performance. Lacking any good metrics to compare the two approaches, seems to me like calculating everything would be preferable to continuously monitoring, if it can be done fast enough. But I can see why you would argue no perf improvement here. You did not answer what you mean by "Clojure aware brackets". But I think I may remember now. I think what you are describing is a thing where, for example, vectors can color cycle separately from lists? Personally I hated that feature because for me it was much harder to tell what forms are opening/closing where from the colors. So, at least for me, there is definitely no sacrifice in losing that.

> Are you saying I need to leave these turned on? I’m a bit confused No, if you don’t like rainbow brackets you should have those disabled. It won’t gain you much performance though, because Calva does almost all that work regardless. It is if you like rainbow brackets, that you can choose between the built-ins and Calva’s.

> vectors can color cycle separately from lists? No, Calva doesn’t do that. I answered above. It is about reader tags being taken into account. I will leave your argumentative comments about Calva’s rainbow performance uncommented, because it will take us nowhere.

> I will leave your argumentative comments about Calva’s rainbow performance uncommented, because it will take us nowhere > Well that wording seems to imply you think I still said something wrong? If that's the case, then "uncommented" is a sure way to make sure that I stay wrong. But, you do you. 😘

If you wonder about something, @U90R0EPHA, just ask. Asserting things and seeing what I correct doesn’t work for me.

I did not think there was something to correct. But you seem to be implying there is. I know quite well that I can be wrong about things, sometimes very wrong. I make it a point to avoid getting locked into something as being true just because I said it was, and stay open to learning from corrections.

I’m sorry for being edgy. If there is something you wonder about how Calva rainbow parens are implemented and try to avoid consuming compute, please ask. But let’s do it in a separate thread.

To close the loop on this - my performance is fine now for a month after disabling all the plugins, this is my current setup. 2022 Mac Studio 128GB ram