Everyone saying "This isn't a speedup, this is VSCode stopping being dumb" hasn't read carefully enough:
The speedup is from taking extension code built on a limited API and implementing it inside VSCode, using more information while doing so.
Odd to read that "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." Especially when I try out "rainbow-delimiters" in emacs and see that it is already quite fast.
I can kind of buy into the idea that "async by default" is a good path to build plugins. It boggles my mind that some of these slownesses are just lived with, though. How many other plugins that haven't gotten the attention of the core team can never get sped up, because of this choice?
Do people really like this type of syntax highlighting? The screenshots in the article to me are a hard to read color soup.
Speed and performance improvements like this are why VSCode has passed Atom and other editors over time.
I suspect that one of these days someone will just bite the bullet and write an abstract syntax tree editor, and eliminate at a stroke all of the "first, we turn the text into an abstract syntax tree" steps that occur in everything from code colourization through folding to code suggestions. (-:
One thing I miss the most from Xcode is the ability to double-click on any delimiter pair ([...], (...), <...>, {...}) to select all text between those delimiters.
I filed an issue against VSCode to get this implemented, but it never got enough upvotes..
Maybe posting about it here is my chance to get it done? :-P
When working on an experimental VSCode plugin recently, I noticed that bracket colorization was at odds with some basic functionality. For example, in comments, I didn't want colorized brackets, I just wanted everything in the same color. That wasn't possible, except for switching the native colorization off completely. Which I did.
I'm sorry but I still prefer sublime text, and it finally fixed syntax folding!
Sublime text also has a cheap way to do auto-completion, it will just look at existing words in the current file, it's often just enough.
I recently noticed, that code window scrolling is a bit smoother and faster with terminal window closed. Could this be one of those "10kx faster" opportunities?
I specialize in software perf & scalability, so read nearly everything I can on the subject, especially concrete cases like this!
That functionality looks pretty nice, anyone knows of an extension to do that in vim/nvim ?
Such an awesome article to read.. how something `simple` can be extremely challenging to execute
I get scolded for to many ifs haha.
Cool, maybe now they can add native titlebar functionality that real document apps have?
And the project referenced is no longer available (or needed, apparently?)
this is old an did appear long time ago already on HD already...
And now make something more production oriented like multi-screen window support, whoops you can't and you buried this feature request in your github. GG.
Monolith vs micro kernels, next round.
[2021]
[dead]
And yet, somehow, no one has done anything to address the inherent issues for colorblind developers. All of these colorization add-ons are woefully inadequate in that regard.
No mature, sensible code allows for 10x performance improvement (let alone...). Every time I see a statement like this I take it as a confession.
But these "micro optimizations" aren't going to win anything!
Just keep everything slow and then everything will be alright.
If you can make something 10k x faster you didn’t so much fix it as just switch it to working correctly as it should have in the first place.
VSCode is a good tool, but it’s unbearably slow, and it breaks my heart that so much development has converged on something written in electron with such a low regard for performance by any measure.