I get scolded for to many ifs haha.
How VSCode made bracket pair colorization faster (2021)
91–100 of 247 posts
Re: How VSCode made bracket pair colorization faster (2021)
#92Earlier quoted context omitted.
The craziest thing to me is the people who are conditioned into believing that it's not slow. I don't know if it's some sort of perverse Stockholm syndrome, or if young developers today are just not familiar with how incredibly fast desktop applications used to be decades ago. I regularly have to completely reboot it because it becomes so unbearably slow, input latency alone often reaches hundreds of milliseconds. An…
It's all about tradeoffs. I like the features I get from VSCode and find its ergonomics outweigh other editors enough that I choose it over them, even if it may not be as fast. Am I conditioned or stupid? (I rarely have to restart it because input has lagged to hundreds of ms. Maybe if that happened regularly to me, I would feel the same as you.)
I think performance complaints about vscode are either from bad extensions/too many OR poor system resources.
When I first started my current job, they gave me a laptop that was under specced due to the high performance laptops being back ordered.
Vscode performed really poorly, but so did everything else. MS teams was the worst offender by far. I had to close every other application in order to join a meeting, lol
Who knew that having 100% CPU and 100% ram usage would slow applications down...
Re: How VSCode made bracket pair colorization faster (2021)
#93Earlier quoted context omitted.
That's surprising to hear, because I use vscode every day and its performance is miles away of any JS apps I've ever used. It truly feels like a native app when it comes to performance, at the same time keeping some "fluidity" of web app (like scale the entire UI with single key press or reloading the entire app like a web page). I'd say I never had issues with vscode performance and actually its performance is a maj…
What CPU do you have? Because even though VSCode is "just" a text editor, I've found it's relatively demanding. A Core 2 Duo, which is admittedly a little old, but which does absolutely fine with vim, is slow to the point of being unusable with VSCode.
I think unfortunately a CPU from 2008 just isn't gonna cut it here. Single thread benchmarks core for core have risen about 4x since then, average core counts have risen 4x, and L3 caches were added. Probably SIMD instructions are a consideration here as well.
That being said I'm a huge fan of prioritizing longevity of computer parts versus constantly upgrading and generating e-waste.
Re: How VSCode made bracket pair colorization faster (2021)
#94Earlier quoted context omitted.
What is faster than vscode? I've tried emacs and intellij and both have slow start up, break up and cause issues more often
sublime is faster from a text editing perspective. less cursor latency, scroll latency, render latency etc. it is significantly faster, like going from 60hz to 120hz. that being said i use vscode due to the remote ssh stuff which is pretty handy. took me a while to get used to the latency everywhere.
I use vscode for interactive python development with Jupyter notebooks and live markdown rendering, and developing on WSL on windows. Does sublime support that? Vscode has the advantage that virtually every programming language and functionality you can think of, it has a plugin for it. Does sublime have similar support?
Re: How VSCode made bracket pair colorization faster (2021)
#95If 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.
> it’s unbearably slow ??? You probably have tons of extensions installed, right? VSCode now features profiles - you can install extensions per, err, profile https://code.visualstudio.com/docs/editor/profiles > 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. Read carefully. The extension API limited the extension performance…
Thanks for mentioning profile support. For some reason I never thought to look into that, even though my own VSCode setup is definitely too cluttered.
Re: How VSCode made bracket pair colorization faster (2021)
#96If 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.
The reason wasn't JS performance or Electron, but simply that bracket colorization was bolted on in an extension which had to make use of the existing extension API, which obviously didn't expose the needed internal features to properly implement bracket colorization.
The exact same thing would have happened in a native editor if its plugin interface didn't anticipate a particular requirement.
Re: How VSCode made bracket pair colorization faster (2021)
#97Odd 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…
Yeah, this was a very uninteresting article to me.
The real challenge would have been to make the extension architecture not terrible. That would have also had the nice side effect of enabling other extensions to become more performant.
Aside from that, the algorithm they described is one an undergrad could come up with. Pure vanity blogpost here.
Re: How VSCode made bracket pair colorization faster (2021)
#98If 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.
Software developers are conditioned to accept horribly slow interactions with their software due to compilers. Most compiled languages have zero regard for developer time with the lengthy compile times. The break in context and flow from those constant delays and the horrible hacks in tooling around trying to deal with it are a constant irritant that has taken root and just accepted.
Re: How VSCode made bracket pair colorization faster (2021)
#99I'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.
Vscode like many text editors supports that kind of completion too, but you should seriously give a try to better completion engines such as GitHub Copilot or StarCoder.
Re: How VSCode made bracket pair colorization faster (2021)
#100If 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.
The craziest thing to me is the people who are conditioned into believing that it's not slow. I don't know if it's some sort of perverse Stockholm syndrome, or if young developers today are just not familiar with how incredibly fast desktop applications used to be decades ago. I regularly have to completely reboot it because it becomes so unbearably slow, input latency alone often reaches hundreds of milliseconds. An…
Your experience is not representative. Input latency of hundreds of milliseconds isn't something anybody I know would tolerate.