8 ms·
How VSCode made bracket pair colorization faster (2021)
- peoplefromibiza 3y ago2021 already submitted two years ago (268 comments) https://news.ycombinator.com/item?id=28692470 https://news.ycombinator.com/item?id=28692470
- dang 3y agoThanks! Macroexpanded: Making bracket pair colorization faster - https://news.ycombinator.com/item?id=28692470 https://news.ycombinator.com/item?id=28692470 - Sept 2021 (265 comments)
- akasakahakada 3y agoBut these "micro optimizations" aren't going to win anything! Just keep everything slow and then everything will be alright. https://news.ycombinator.com/item?id=36401488 https://news.ycombinator.com/item?id=36401488
- ghnws 3y agoThis is not micro optimization. This is fixing a known performance issue.
- jokoon 3y agoI'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.
- speedgoose 3y agoVscode 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.
- tredre3 3y agoI mean you don't need a cloud connected AI to significantly improve your experience in VS Code (vs basic token autocomplete). Just installing the proper LSP for the language you work in makes a world of difference.
- Narishma 3y agoDo people really like this type of syntax highlighting? The screenshots in the article to me are a hard to read color soup.
- yoyohello13 3y agoYeah, I find the 'every symbol has a color' highlighting to be difficult to parse. When everything is colorful, nothing stands out.
- cubefox 3y agoIt's very useful when trying to find matching brackets in code!
- akamoonknight 3y agoIn just basic Vim, there's highlighting such that if the cursor is over a start bracket (or end bracket), the opposite bracket is highlighted. I do find that very helpful indeed to find matching brackets (or where a bracket is missing), but I can't quite see why I'd need to have the colorization as well. Essentially I guess I can see colorization as 'highlighting' multiple brackets at once. Any way you could convince me that having this multiple identification has been preferable to the single identification?
- cubefox 3y agoI recently switched from an old VScode version, which has only the click dependent matching, to the new version which has it with color highlighting. The difference is that you can match brackets pretty much immediately by glancing at them. It's convenient because it is quicker.
- akamoonknight 3y agoGotchagotcha, so yeah, to some extent eliminates the time taken to highlight individual brackets at the cost of adding some visual complexity. Thanks.
- Solvency 3y agoAnd 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.
- kaveet 3y agoAny interest in working together on a new extension?
- nsajko 3y agoSee XKCD: "How standards proliferate".
- deleted 3y ago[deleted]
- Conscat 3y agoNo, that's not relevant and I think you know it, funny man
- iamgopal 3y agoWhat would be the possible solution ? Change size ? High contrast fg/Bg combinations ? Special UTF characters?
- sudosysgen 3y agoA different spectrum per type of colorblindness. It should work fine, unless you're completely blind to all colors, which is a very small proportion of colorblindness, most are only lacking perception of one out of three colors.
- arijun 3y agoYou can already do that: in the settings.json under workbench.colorCusomizations, change editorBracketHighlight.foregroundX where X is the level of bracketing you want to modify. In practice, though, the reduced color vision combined with the small target that is a bracket (color vision degrades for smaller objects), means that this is of limited usefulness.
- arijun 3y ago[2021]
- dtagames 3y agoAnd the project referenced is no longer available (or needed, apparently?)
- lkbm 3y agoThe speedup is not the extension v1 to v2, it's extension v2 to implementing the feature in vscode. They talk a bit about how there's a fundamental limitation in the extension speed given the current (as of 2021) extension API.
- voz_ 3y agoIf 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.
- Solvency 3y agoThe 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. And this is on a workstation that I use to render extremely sophisticated 3D animations.
- conductr 3y agoI know it's electron and a resource hog, meanwhile I virtually never need to reboot it and it never lags for me and I can't recall it crashing on me. Maybe I don't type fast enough to notice some of the laggy behavior but that's how I'm conditioned to believe it's just fine for me and I run it on a MB Air. I've used several IDE's over the years and feel like if I had something performance-wise to complain about I would have noticed it by now.
- edgyquant 3y agoI’ve no idea what you’re on about, and I come from CLI editors (vim.) VSCode is not slow at all for me, no latency I can readily see. My only complaint is that LiveShare is incredibly buggy and my team does a ton of pair programming.
- Atotalnoob 3y agoLive share is an amazing thing that Microsoft demos. Doesn't really work (in my experience) in the real world...
- rafaelturk 3y agoSuch an awesome article to read.. how something `simple` can be extremely challenging to execute
- butz 3y agoI 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?
- Avlin67 3y agothis is old an did appear long time ago already on HD already...
- sudoapps 3y agoSpeed and performance improvements like this are why VSCode has passed Atom and other editors over time.
- omazurov 3y agoNo mature, sensible code allows for 10x performance improvement (let alone...). Every time I see a statement like this I take it as a confession.
- XCSme 3y agoWhat if after a long research, you can change the complexity of an algorithm from O(N) to O(log N), which makes the code orders of magnitude faster on large datasets. Does it mean the original code was not "sensible code"?
- HL33tibCe7 3y agoYou didn't even bother reading the article, did you? The performance increase was achieved by inlining a third-party extension into VSCode itself.
- gopher_protocol 3y agoI know reading the article is hard, but if you did you'd realize that it was slow because colorization was performed by an extension, and could not be optimized sufficiently because of limitations of the public API. They sped it up by moving it into the VS code core, which allowed it to take advantage of a bunch of features not available to extensions.
- ARandumGuy 3y agoI mean, in this situation a big thing is taking a plugin and re-writing it as part of the core application. The initial plugin was inherently limited by the existing plugin API, which wasn't optimized for this specific use case. "We improved a popular plugin by integrating it with our core application" doesn't feel like a confession to me. In fact, that's exactly what I'd like to see from an application developer. No application is perfect, and it's good when developers improve the basic look and feel of an application based on what their users want.
- compiler-guy 3y agoThe code was both mature and sensible _within the limits of the environment and API available to it_. The VSCode team took it out of that environment completely, which opened up a huge number of optimization possibilities.
- frankreyes 3y agoMonolith vs micro kernels, next round.
- taeric 3y agoOdd 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?
- bagacrap 3y agoYeah, 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.
- robertoandred 3y agoCool, maybe now they can add native titlebar functionality that real document apps have?
- tomcatfish 3y agoEveryone 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.
- bluSCALE4 3y agoI read it as extension developers will never be able to match core since their api is limited.
- mynameisvlad 3y agoI mean, yes? That's kind of the point of extensions; to provide additional functionality through specific APIs. Chrome/Safari/Firefox extensions certainly don't have full access to everything the browser can do. Nor can IntelliJ plugins. Nor can... practically any other implementation of extensions. https://github.com/microsoft/vscode https://github.com/microsoft/vscode is available if a developer wanted to contribute something to core, anyway.
- taeric 3y agoEmacs stands in stark contrast to this claim, though. Some things do get moved into native code so that it can run faster, but at large most of it is implemented in the same code and paths that everyone has access to at runtime. (For examples of "to run faster," I'm talking of json and such. Calling out to the tree-sitter library is there, too. I'm not clear why that has to be native, oddly.) I can certainly understand and agree with browsers having more locked down sections. For expert developer tools, though, it does feel a touch weirder.
- tiku 3y agoI get scolded for to many ifs haha.
- bick_nyers 3y agoI'll take verbose code over code golf any day.
- nephanth 3y agoThat functionality looks pretty nice, anyone knows of an extension to do that in vim/nvim ?
- practal 3y agoWhen 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.
- RektBoy 3y agoAnd 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.
- steve76 3y ago[dead]
- JdeBP 3y agoI 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. (-:
- tomtom1337 3y agoThat is what tree-sitter is, I think? https://tree-sitter.github.io/tree-sitter/ https://tree-sitter.github.io/tree-sitter/
- nielsbot 3y agoOne 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 https://github.com/microsoft/vscode/issues/85587 https://github.com/microsoft/vscode/issues/85587
- jcparkyn 3y agoNot quite what you're asking for, but you can click after the first bracket and then use the "Go to bracket" command to get roughly the same thing. You'll have to add a keybind for it though, there isn't one by default. For slightly more control, you can also use alt+shift+right (or left) to expand/contract your selection to the matching bracket.
- syngrog66 3y agoI specialize in software perf & scalability, so read nearly everything I can on the subject, especially concrete cases like this!