[HN Gopher] How VSCode made bracket pair colorization faster (2021)
___________________________________________________________________
How VSCode made bracket pair colorization faster (2021)
Author : s3arch
Score : 188 points
Date : 2023-06-22 15:06 UTC (7 hours ago)
(HTM) web link (code.visualstudio.com)
(TXT) w3m dump (code.visualstudio.com)
| Avlin67 wrote:
| this is old an did appear long time ago already on HD already...
| Solvency wrote:
| 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.
| kortex wrote:
| Can't you just define the symbol color pallet in options? (I'm
| not a vscode user, I use JetBrains and I just define my own
| colors)
| tredre3 wrote:
| You absolutely can define your own colours. You can even have
| different colour pools per bracket type ([] () {}) if you
| want.
|
| Given that colour blindness is a wide spectrum, I don't know
| what more people expect VS Code to do here?
|
| Your chosen theme decides the original colours, then you can
| override them. Isn't that enough?
| kaveet wrote:
| Any interest in working together on a new extension?
| nsajko wrote:
| See XKCD: "How standards proliferate".
| [deleted]
| Conscat wrote:
| No, that's not relevant and I think you know it, funny man
| iamgopal wrote:
| What would be the possible solution ? Change size ? High
| contrast fg/Bg combinations ? Special UTF characters?
| jkaptur wrote:
| Subtle distinctions in font weight or italic-ness? Variable
| fonts give a lot of options.
| sudosysgen wrote:
| A 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 wrote:
| You 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.
| Solvency wrote:
| Mathematic notation uses subtle tweaks/additive glyphs to
| the same characters all the time.
| quietbritishjim wrote:
| Seems like a fundamentally unsolvable problem. These techinques
| use a spectrum of colours for deeply nested brackets. (If you
| only have one or two levels of brackets then you don't need the
| colourisation in the first place.) But colourblind users
| fundamentally don't have that many choices of colours to pick
| from in the first place.
| aleksiy123 wrote:
| Maybe they could use a superscript or subscript number
| instead?
| Conscat wrote:
| Modus Operandi provides accessibility options for colored
| bracket pairs in Emacs out of the box.
| pmarreck wrote:
| It's not unsolvable. Colorblind people are missing one axis
| of color (such as the red-green axis). It is perfectly
| mathematically possible to pick colors that do not only
| differentiate along this axis, hence this option in many AAA
| games.
|
| Here's an online simulator to see what colorblind people of
| various types see. Note that if you yourself try this and the
| colors for one of the examples don't seem to change from the
| "normal" version, see your eye doc...
|
| https://daltonlens.org/colorblindness-simulator
| kaveet wrote:
| This might be my own personal experience, but one effect of
| my colorblindness is that I place far less emphasis on
| color-coding in the real world--I'll subconciously ignore
| things like status indicators. When I think of alternative
| solutions here, I tend to reach for variables like font
| weight instead.
| [deleted]
| dmonitor wrote:
| just the ability to change the bracket colors with
| reasonable default selections for colorblindness seems like
| a more than reasonable request
| bilalq wrote:
| The extension already had a setting to tune the color
| palette even before it was merged into VSCode core.
| devbent wrote:
| I use a space indent colorizer plugin that I use a grey scale
| color scheme with.
|
| It isn't a complete replacement for bracket colorization, but
| it helps in a lot of cases.
|
| (Not colorblind, I just prefer a grey scale theme for my
| indent reminders!)
| peoplefromibiza wrote:
| 2021
|
| already submitted two years ago (268 comments)
|
| https://news.ycombinator.com/item?id=28692470
| dang wrote:
| Thanks! Macroexpanded:
|
| _Making bracket pair colorization faster_ -
| https://news.ycombinator.com/item?id=28692470 - Sept 2021 (265
| comments)
| arijun wrote:
| [2021]
| nephanth wrote:
| That functionality looks pretty nice, anyone knows of an
| extension to do that in vim/nvim ?
| sudoapps wrote:
| Speed and performance improvements like this are why VSCode has
| passed Atom and other editors over time.
| JdeBP wrote:
| 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. (-:
| tomtom1337 wrote:
| That is what tree-sitter is, I think? https://tree-
| sitter.github.io/tree-sitter/
| dtagames wrote:
| And the project referenced is no longer available (or needed,
| apparently?)
| lkbm wrote:
| The 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.
| steve76 wrote:
| [dead]
| voz_ wrote:
| 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.
| theRealMe wrote:
| "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."
|
| There's a word for what you are trying to explain. The word is
| "fix".
| dsab wrote:
| I am working as embedded software developer and VSCode is
| extremaly fast compared to its first competitor - Eclipse.
| akkad33 wrote:
| What is faster than vscode? I've tried emacs and intellij and
| both have slow start up, break up and cause issues more often
| whalesalad wrote:
| 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.
| akkad33 wrote:
| 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?
| dumdumchan wrote:
| Intellij does this in constant time because it has AST
| functionality built in.
| EMM_386 wrote:
| > 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.
|
| I'm on a 3+ year old laptop writing enterprise Angular on it
| with numerous plugins and it's very fast.
|
| I feel like your view may be impartial due to a dislike of
| Electron over native applications.
| paulddraper wrote:
| !!!
|
| VSCode as fast as IntelliJ, Eclipse, PyCharm, Visual Studio.
|
| (And anyone upset about Electron install sizes has clearly
| never used any of the above.)
| [deleted]
| david2ndaccount wrote:
| > look, I'm sorry, but the rule is simple: > if you
| made something 2x faster, you might have done something smart
| > if you made something 100x faster, you definitely just
| stopped doing something stupid
|
| <https://twitter.com/rygorous/status/1271296834439282690?lang..
| .>
| seventhson wrote:
| It might be stupid, or it also might just be naive, or a
| shift in priorities.
|
| 100x throughput improvement might just come from caching
| results from earlier computations (less naive) - at the cost
| of 10x memory footprint possibly (different priorities).
| alberth wrote:
| It's unfortunate that oni2 development stopped.
|
| It had the promise of all the benefits of VS Code, but
| performance of a native app.
|
| https://v2.onivim.io
| bilalq wrote:
| I disagree with all points here.
|
| The speed performance became possible by being able to
| implement this within VSCode's core rather than over the
| extensions API. Without proving the value proposition as an
| extension first, it'd be difficult to get a change like this
| merged into core at the start.
|
| Also, VSCode is by far the fastest IDE I've ever used. I
| occasionally need to interact with IntelliJ, Android Studio,
| and XCode. The difference in responsiveness is night and day.
| Before VSCode, I would almost exclusively just use Vim. It's
| silly to be bashing it as a "slow" Electron app when it's
| measurably way faster than XCode, a native IDE developed by a
| company with an integration advantage of being in control the
| underlying OS and hardware.
| specialist wrote:
| Yes and: Make it work, then make it correct, then finally
| make it fast.
| uoaei wrote:
| In what world would it be needed to prove the value
| proposition of "users can see which open brackets are
| associated with which close brackets"? Thus just seems
| blindingly obvious to me and probably anyone who's spent more
| than 40 hours writing code.
|
| > It's silly to be bashing it as a "slow" Electron app when
| it's measurably way faster than XCode
|
| One of my favorite mis-applications of opportunity cost from
| the perspective of developing features, and one I see
| constantly in market-brain types: the comparison is not on
| competing offerings but on whether the feature is present or
| not.
| SketchySeaBeast wrote:
| > In what world would it be needed to prove the value
| proposition of "users can see which open brackets are
| associated with which close brackets"?
|
| One where there is finite time and resources and you have
| to pick and choose what you tackle. I could easily see this
| being ignored knowing that VSCode is so extensible and the
| community could easily pick up the missed non-core
| functionality until there was time to do it right.
| bilalq wrote:
| Maybe blindingly obvious in hind-sight, but none of the
| IDEs I mentioned in my last comment have this feature. Nor
| does any other IDE I've ever used. It's not hard to imagine
| why a novel feature, without much prior art, potentially
| sitting on the blocking path for UI rendering, and
| contributed by an external person would face friction in
| being merged into core. Not to mention the onboarding
| complexity of making a change like this in core vs as a
| standalone extension for a new contributor.
|
| Also, I don't understand at all what your last sentence
| there means.
| b5n wrote:
| It's always entertaining to me to see 'new'(ish) IDE
| features being lauded that have already been available in
| emacs for years, if not decades.
| vladvasiliu wrote:
| After a quick search through the settings, IntelliJ seems
| to indeed not have bracket colorization. I seem to
| remember there was an option for this, but it may have
| been a 3rd party plugin.
|
| However, it has something that I find superior: when
| you're on a bracket, it will highlight its opposing
| bracket (closing if you're on opening, and vice versa).
|
| The reason I think it's superior is that you can see
| directly which specific bracket you're looking for, you
| don't have to hunt for the corresponding shade. And in
| case your brackets are unbalanced, you'll see it
| directly.
| jve wrote:
| > seems blindingly obvious
|
| Well, for me it IS helpful when the code block doesn't fit
| on single screen and I have to scroll AND there are
| multiple levels of brackets. Usually I try to put a cursor
| and not move it vertically and scroll to see where it ends.
| And coloring helps here.
|
| Sometimes I want to understand - hey, where is the closing
| bracket, because there are 3 openings on single line, some
| expressions formatted on some lines, typecasts and whatnot
| that litters () around. Format document may not help there
| to align everything if I got any bracket missing there.
|
| And I usually exit early, trying not to make too nested
| constructs, not using excess (), prefer constructs that
| eliminate brackets altogether. Anyways, not always we read
| our code. Of course python people can laugh that they don't
| even have such an issue, but others have, you know.
| EMM_386 wrote:
| > Well, for me it IS helpful when the code block doesn't
| fit on single screen and I have to scroll AND there are
| multiple levels of brackets.
|
| Maybe they'll port this feature to VS Code.
|
| I tried it out, solves the problem you mentioned.
|
| https://devblogs.microsoft.com/visualstudio/sticky-
| scroll-st...
| tetha wrote:
| Yeah, I'm a bit put off by the comments there.
|
| Like, yeah. Neovim is faster and smaller than VSCode, by a
| lot on smaller hardware. And I'm pretty sure I could summon
| my experiences from 5 years ago or so of really putting
| effort into my vim setup to have many of the goodies of a
| modern IDE, like LSP support, search, highlighting and so
| forth. But sorry, if I do that, I'd have to spend like 8
| hours to integrate a new language based on past experiences.
| Instead of just dumping an extension into a new derived
| profile in vscode and be done with it. And then we think
| about teammates who aren't as fluent in vim. Even if my
| Neovim/Vim setup might be faster or lower input latency at
| times, it won't give me that day of initial integration back,
| ever.
|
| And honestly, if I think about slow editors, I think about
| old Eclipse builds. Maybe with bad plugins, bad Maven
| versions, or horribly customized to some embedded or
| enterprise or academic use case. Bonus points if used on
| shitty corporate hardware. That's a level of slow called
| "Looking up documentation in a browser ends up being faster
| than auto complete". Compared to those molochs, VScode is not
| slow at all if you look out a bit for plugin overload.
| paulddraper wrote:
| You don't understand.
|
| Electron = slow and big install
|
| Even if other tools are objectively slower and bloatier, it
| is a immutable law that Electron = slow and big install
| geodel wrote:
| I think people are needlessly disparaging this beautiful,
| fast, lightweight tool.
|
| These look similar to haters who claimed horse cart can't
| be faster than automobile once some performance
| optimizations are put in place.
| JohnFen wrote:
| I have literally never seen an Electron-based application
| that wasn't overly bloated and slow to start up.
|
| I have seen a tiny number that performed decently once
| running, but they are the exceptions.
| frogstomp19 wrote:
| We're discussing one right now. VSCode is an electron-
| based application, isn't overly-bloated, and starts up
| quickly. I switch between IJ and VSC every day and VSC is
| significantly faster, including startup. But, even if it
| _was_ slower on startup, that would be a tradeoff I'd be
| happy with if it was faster or more functional normally.
| I restart my computer maybe once a week, I'd be fine to
| wait another couple seconds.
| JohnFen wrote:
| VSCode is better than many, but I do think it counts as
| bloated, has reasonably high recommended machine
| requirements, and performs more poorly than I would
| expect of such an application.
|
| It does perform better than IJ and the like, but that's a
| bit of damning with faint praise.
|
| I don't comment beyond that on it as I don't use it more
| than I have to (for reasons unrelated to it being
| Electron-based) and want to avoid Speaking Of That I Know
| Not. I was speaking about Electron more generally.
| EMM_386 wrote:
| > Electron = slow and big install
|
| This isn't the 1990s. My username alone should show I went
| through a period where the size of the binary and the
| memory size mattered.
|
| These days with have gigabyte/terabyte hard drives and
| gigabytes of RAM. It generally sits unused and the O/S will
| handle reallocating if you really put the pressure on.
|
| I'm not too concerned about VS Code hitting my RAM cap.
| Right now, with the entire front-end of a large enterprise
| application loaded, it's using 350 MB of RAM.
|
| Meaningless in the grand scheme of things. And it's fast,
| on a 3 year old laptop.
| hwbehrens wrote:
| To those who are missing it, the parent comment ^ is using
| sarcasm.
| mypalmike wrote:
| "Don't be snarky" is mentioned in the first rule of hn
| commenting. To be fair, I don't always abide by it
| either, but it's a good rule.
| paulddraper wrote:
| Yeah :/
| leidenfrost wrote:
| Even if that's true, there should be a reason, or a cause
| at least, that VSCode dominated over most IDEs out there.
|
| In my experience, other IDEs have either a really high
| learning curve, needless bloat, or are closer to a notepad
| with extra features rather than a full fledged developing
| environment.
|
| You can open VSCode and be welcomed by a lot of development
| features right on your face and wander through a lot of
| recommended add ons that add extra value out of the box.
| Also, since is electron based, multiplatform support is a
| no brainer.
|
| Meanwhile, everyone is absolutely free to create a native
| VSCode clone. But that isn't happening at least for now.
| Maybe UI toolkits are a mess, maybe trying to mimic an UI
| in a 2D library is a PITA, maybe it's that an extensions
| engine needs to implement some "easier to develop" language
| (like javascript or Lua) and a full fledged interpreter for
| it, and it's so much work one would rather stick with
| Electron and be done with it.
|
| Everyone hates VSCode, but nobody ever has managed to offer
| a competing alternative.
| IceSentry wrote:
| It's barely alpha, but lapce is kinda trying to be a
| native version of vscode.
|
| https://github.com/lapce/lapce
| [deleted]
| voz_ wrote:
| Comparing with Xcode is a joke.
| wiseowise wrote:
| Is Xcode native app?
| KnobbleMcKnees wrote:
| Point stands about bashing electron for not being native,
| even if Xcode is a dumpster fire.
| wongarsu wrote:
| Compared to Sublime Text VSCode is sluggish and hilariously
| bad at handling large files. Compared to Android Studio,
| VSCode is lean and very fast.
|
| In my opinion it's in a comfortable "fast enough" position,
| and from the very beginning the VSCode team has shown a great
| dedication to having the best possible performance in the
| particular technology stack they have chosen. It's just
| equally true that they have chosen a technology stack that
| puts easy extensibility over performance.
| misnome wrote:
| I switched away from sublime text because it only had a
| fraction of the features and extensions. Perhaps I'm just
| not using files large enough, most of our source modules
| top out at a few thousand lines of code.
|
| And VSCode could be much, much worse. I tried AstroNvim on
| neovim for a while after it got some attention here. It
| consistently started up slower for me than VSCode does.
| srik wrote:
| Compared to the others neovim should theoretically be
| snappier. Could it be bogged down by 3rd party plugins or
| something? If so try to switch to the lazy.nvim plugin
| manager which does a great job of lazy loading plugins,
| but more importantly allows you to profile the startup
| time and tweak loading mechanisms until you find a
| desirable balance between loading plugins and
| startuptime.
| alwillis wrote:
| +1 for Lazy: https://github.com/folke/lazy.nvim
|
| For me, Neovim has always been faster than VS Code and
| that was before switching to Lazy plugin manager.
| hakunin wrote:
| Just an anecdote for those curious about a specific
| experience.
|
| This time I used VSCode for nearly 2 months. Thought it's
| the end of an era, I'm not coming back to Sublime Text. I
| decided to push through and customize the configs just
| right for me, it was really becoming comfortable. Main
| reason why I wanted to switch is more active dev, more
| active extension community, and well integrated modern
| (some ML-backed) code writing and navigation tools.
|
| I was wrong. After all the painstaking customization to
| bring it close to my ideal experience, while also getting
| used to things I didn't want to fight, I still had a bad
| time.
|
| For one, the tab/cursor focus keeps going into weird
| places. I press a button, like ESC to switch to normal
| vim mode, and instead it does nothing, or something
| different, because turns out I'm not in the editor
| anymore. Keeps happening, maybe my own fault. The nifty
| AI tools integration is more of a nuisance -- they jump
| in at bad times (with a delay), and their tab/enter
| functionality is weird, can never get it right. Most of
| my autocompletes have been unintentional. Maybe my own
| fault again, but felt super awkward. There is still no
| good vertical align plugin, despite such an active
| community (Sublime doesn't have one either, although they
| have one that gets me a bit closer). The language server
| stuff that worked badly in Sublime for my language also
| works badly in VSCode. The extensions, while numerous,
| are of questionable quality. I tried to stick to just a
| few well known ones.
|
| After all the effort, I slowly came to realization that
| I'm back to not really using anything unique to VSCode,
| sacrificing more than I gained, being surrounded by lots
| of small moving details everywhere in the UI that make my
| experience more awkward than helpful, and occasionally
| getting my cursor stuck in weird parts of UI. I went back
| to Sublime.
| ElectricalUnion wrote:
| > Compared to Android Studio, VSCode is lean and very fast.
|
| It was most likely some specific detail of my previous old
| piss-poor Windows work computer environment but the ad-hoc,
| whole project + all_java_dependencies + entire_jdk full
| file scanning on every single file opened (no matter if it
| was the same file opened) by the Visual Studio Code for
| Java Language Service (remember, it's Windows, so under
| molasses slow file access/reading) made everything
| extremely painfully slow for me in Visual Studio Code.
|
| Granted, JetBrains IntelliJ took 50s+ to open the project
| in such bad environment but it didn't constantly _rescan
| the whole thing_ every time another file was opened.
|
| Things seems to have been improving a lot ( _Visual Studio
| Code for Java Language Service Lightweight Mode_ and
| _JetBrains Fleet Lightweight Mode_ comes to mind) since
| that, but it is still the reason why I use those JetBrains
| IDEs at all.
| 411111111111111 wrote:
| The issue is that you tried to use vs code for Java. That
| plugin doesn't really work well, honestly.
|
| The performance would have been pretty much the same if
| you used it like sublime text, so no plugins beyond
| synthax highlighting
|
| And before someone claims that's not fair because sublime
| text has plugins too: no, it (to my knowledge) doesn't
| have any that enable the same classpath scanning vs code
| (and intellij or eclipse) does for java
| wiseowise wrote:
| Sublime Text in no way represents "average" native
| application. It doesn't even use native GUI toolkits, ffs.
| pcthrowaway wrote:
| Sublime Code isn't an IDE
| drcongo wrote:
| "Sublime Code" isn't a thing at all.
| faangsticle wrote:
| By that measure neither is vscode. Both are extensible
| text editors with ide plugins available.
| pcthrowaway wrote:
| I guess I didn't realize Sublime has had LSP packages for
| a while now, though IIUC it still doesn't support it out
| of the box
| HL33tibCe7 wrote:
| You're overlooking the fact that the reason that VSCode is good
| is precisely that electron enables a high development velocity.
|
| Edit: also, if you read the article, you'll find that the 10k x
| performance increase is a comparison between the performance of
| a third-party extension and the performance once that extension
| has been rewritten and inlined into VSCode itself. It's not
| like they were being accidentally quadratic or something.
| lkbm wrote:
| I switched from Pycharm to VSCode because on my 2015 MBP,
| Pycharm was too sluggish. (Mostly a memory hog, I think.) Now
| that I'm on an M1 Max, vscode feels completely unconstrained,
| and I suspect Pycharm would as well.
|
| Though, to be fair, I did actually run into an actual
| "borderline-frozen" situation yesterday doing a regex search
| that matched a bunch of very long lines in a log file.
| hinkley wrote:
| I still use Jetbrains but I don't really push it on other
| people the way I used to. It was always a pig, but it was less
| of a pig than Eclipse, which I haven't met anyone who still
| uses it in a long time, so now Jetbrains is "the pig ".
|
| I figured the targeted versions would fix that, but I haven't
| found that to be the case, or at least not for mature projects.
|
| Point is, VSCode isn't trying to be good, it's just trying to
| be better than Jetbrains. Which is a nearly universal failure
| mode in this industry, and why it takes us so long to get good
| tools. If someone throws a terrible tool out, we have to go
| through two or three generations of replacements before someone
| finally has an original idea that isn't built on the misguided
| one we started with.
|
| The bones for running other languages or enhanced Java on the
| JVM were laid down in Java 1.2, but the first assembler built
| for Java was terrible. It wasn't even a macroassembler, you had
| to do your own pointer arithmetic for the stack and IIRC for
| the constant pool. It was two assemblers later before we got
| one that made me say, "this is actually pretty usable" and I
| don't think it's a coincidence that the number of JVM languages
| basically doubled a short time after that. We could have had
| all of this in 1998, not 2008.
| Solvency wrote:
| 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. And this is on a
| workstation that I use to render extremely sophisticated 3D
| animations.
| phpisthebest wrote:
| >> how incredibly fast desktop applications used to be
| decades ago
|
| Are you still using that same computer from decades ago?
| xigoi wrote:
| If the applications could be fast on that computer, why
| can't today's applications be fast on the same computer?
| xigoi wrote:
| They probably have a powerful computer for $10k and don't
| understand that many people don't.
| bemusedthrow75 wrote:
| I've never ever run it on a $10K computer. It's quick
| enough on a Surface Go 2 (albeit in Linux, not on Windows).
| It's quick enough on an eight year old 2.7ghz i5 MacBook
| Pro. And it's even not shockingly awful on an 8GB Raspberry
| Pi 4B.
| bemusedthrow75 wrote:
| So if I don't find it to be slow, I am not just wrong but
| delusional?
|
| VSCode with the Remote SSH mode has absolutely, objectively,
| sped up everything I do. It's easier to work on remote
| machines as if they were local, it hasn't ever seemed
| keystroke-slow (either on a 2015 Macbook Pro or a recent Core
| i3 thing -- a Surface Go 2 running Ubuntu).
|
| It has made it feasible for me to use integrated Git support
| in a remote environment, it has made remote file searches
| actually useful, it's worthwhile to make use of language
| servers (even for PHP!), and it presents substantially the
| same UI wherever I work.
|
| It is not noticeably interactively slow.
|
| But if it was slightly slower than, say, TextMate or
| SublimeText, the cost of that interactive slowness would
| likely be more than offset by the sheer productive utility of
| the thing, and no longer needing to treat host, local VM and
| remote VM environments differently.
|
| It is in sum enormously faster than anything else I've used.
|
| But this is just the deranged ramblings of a kidnap victim?
| bemusedthrow75 wrote:
| And FWIW, I _wish_ I was a "young developer"!
|
| I am not.
|
| But I wouldn't seek to patronise them either, or describe
| their thinking as "perverse".
| drcongo wrote:
| [flagged]
| [deleted]
| flohofwoe wrote:
| I switch between Visual Studio, Xcode and VSCode pretty much
| each day for C/C++ development, and out of those VSCode is by
| far the slickest to use (and also the most flexible). I'm
| also not exactly a newbie, having started to code in the
| mid-80s. I also tried out all the IntelliJ IDEs, and _for
| those_ I cannot understand how people can put up with the UI
| sluggishness :)
|
| Also: even Vim (which I often use for quick text editing
| tasks on the terminal) can get embarrassingly slow on large
| files if you start installing extensions.
| AnIdiotOnTheNet wrote:
| > 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.
|
| Most of them have no idea how fast a computer is because
| they've been using ludicrously slow software for so long they
| just think that's normal. Microsoft developers these days
| seems to have a particularly warped understanding of what
| "fast" means in computing, see Teams startup times [0], VS
| startup times [1], or that whole debacle with Windows
| Terminal.
|
| [0] https://twitter.com/i/status/1640972391265230848
|
| [1] I couldn't find a video in a reasonable time frame, but
| it is very slow compared to its predecessors just to _launch_
| let alone do anything that might justify it.
| bigbillheck wrote:
| > not familiar with how incredibly fast desktop applications
| used to be decades ago
|
| I have very clear memories of desktop applications from
| decades ago, and how incredibly fast they were, and it's "not
| at all", because they were slow as heck.
| zwily wrote:
| 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.)
| Atotalnoob wrote:
| 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...
| grog454 wrote:
| Some people can't tell the difference between 17 ms of
| latency and 68 (4 frames at 60hz), while some can't bear it.
| dimmke wrote:
| Just curious - are you running some kind of debugger or
| profiling software through VSCode?
|
| Because VSCode is very fast to me, and I experience literally
| no input latency at all. And I have used Electron based code
| editors that felt slow to me. Like, Atom always felt very
| slow to me.
|
| This isn't a vehement defense of Microsoft or VSCode - I wish
| the industry had consolidated on something else, but it's the
| way things are right now. You don't have to use it, there are
| plenty of alternatives.
| NovemberWhiskey wrote:
| > _how incredibly fast desktop applications used to be
| decades ago._
|
| ... that 'd be during the time period when WordStar 5.0 would
| have to load an overlay from the floppy drive (taking a few
| seconds at least) in order to, e.g. print, and the speed of
| spell checking was such that you could actually follow along
| as the checker scanned through your document?
| yCombLinks wrote:
| Decades ago also occurred decades after that. The average
| desktop app in 2003 felt faster than the average desktop
| app in 2023. The fact that you chose an app from 1983 shows
| you're intentionally dishonest.
| mtizim wrote:
| I don't think he is intentionally dishonest. When I read
| "decades ago", I thought "three or more", roughly the
| same way "several" works.
| conductr wrote:
| I 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 wrote:
| I'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 wrote:
| Live share is an amazing thing that Microsoft demos.
|
| Doesn't really work (in my experience) in the real world...
| dlisboa wrote:
| I think that's part of the issue that polarizes people:
| it's not consistently slow and it's not consistently fast.
| So you get people who can't understand how it's usable, and
| others who can't understand how anyone has a problem with
| it.
|
| Some other editors are consistently fast, for everyone,
| always (like [n]vim). Not because they're special but
| editing text just isn't that big a deal and these editors
| don't try to do too much graphically, so their performance
| is great.
|
| Another problem is the combination of extensions probably
| has a significant impact on performance and resource usage.
| So person A uses it to edit JavaScript and has no problem,
| but person B uses it to edit Ruby and has one. It might not
| even be VS Code's fault, maybe an extension, but it is seen
| as if it's the editor since it's a whole package and the
| input latency is what's suffering.
| nickelpro wrote:
| Neovim isn't immune to slow plugins, it's just a smaller
| ecosystem and therefore has less exposure.
|
| My two cents, I've never seen a case of "VSC is slow"
| that isn't user error in this vein or on codebases that
| don't struggle similarly with similar tools. Ex, if
| clangd is struggling with your million file codebase
| under VSC it doesn't somehow become more responsive under
| Neovim.
|
| And ya, anecdotally, I've never seen input latency
| specifically move an inch. The VSC team lives and dies on
| input latency and it shows in the current product.
| drcongo wrote:
| [flagged]
| ddoolin wrote:
| There's a difference between "bringing up its slowness" and
| telling everyone else it's slow for them, too, and they're
| just crazy.
| ddoolin wrote:
| This is a pretty condescending take, particularly for someone
| with such an extraordinary issue with VS Code. It is not that
| slow for the rest of us.
| chrisweekly wrote:
| Your experience is not representative. Input latency of
| hundreds of milliseconds isn't something anybody I know would
| tolerate.
| ramraj07 wrote:
| The irony is here by far so many devs don't mind the speed?
| AnIdiotOnTheNet wrote:
| A statement like this just makes me think most developers are
| the passengers in that episode of futurama where the brains
| take over and make everyone stupid.
|
| "I'm sending in more trains!" [0]
|
| Only the trains are additional layers of abstraction and the
| accompanying bloat.
|
| [0] https://www.youtube.com/watch?v=-hyttagGsz0
| [deleted]
| jaywalk wrote:
| It's not the fastest IDE out there, but it's certainly not
| unbearably slow.
| akkad33 wrote:
| I wish people criticising vscode's slowness would give faster
| options. It can't be any Jetbrains ide because I've used them
| all and they can be slow as hell, and buggy especially when
| pulling new changes. No wonder they are playing catch up with
| vscode with their fleet ide.
| 3836293648 wrote:
| That really depends. I used it on the same machine and it was
| fine enough on linux and completely unusable on windows. Same
| extensions, same project.
|
| That was a few years ago now and I've since moved away due to
| its performance issues, though ironically I then found myself
| switching again to Emacs which is definitely slower than VSC
| RektBoy wrote:
| Don't forget, NO multi-screen/window support, which is
| ridiculous. Apparently everybody code on 40" TV screen or
| something, rofl.
| AnIdiotOnTheNet wrote:
| To be fair, non-electron full-fat Visual Studio is also a pig.
| deepspace wrote:
| Calling it a pig is an understatement. It is unbearably slow.
| I have no idea how they managed to make a native app so slow.
| KeplerBoy wrote:
| VSC feels outright snappy compared to regular Visual Studio or
| Eclipse. Of course one can easily bog down VSC with a bunch of
| bad plugins, but i really can't complain.
| deepspace wrote:
| Yes, Visual Studio is unbearably slow for me, even with tiny
| projects, whereas VSC seems snappy, even with larger
| projects.
|
| I also use CLion, and it is quite slow for a few minutes
| after startup (though never as slow as VS), but then becomes
| fast as it finishes indexing or something.
| XCSme wrote:
| Well, sometimes to make things 10k x faster you need to
| implement some really complex algorithms. Implementing a
| trivial solution doesn't mean that it was broken or wrong in
| the first place.
|
| Imagine saying "machine learning" was broken because now it's
| 10k x faster to train using a dedicated TPU than a CPU, so we
| should have used TPUs from the start.
| jve wrote:
| > 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 - so they implemented it in core. It was not a
| builtin feature of VSCode before. From article:
|
| >> 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...
|
| >> 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...
|
| >> 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...
| brirec wrote:
| 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.
| vbezhenar wrote:
| 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 major factor why I use it.
| stewartmcgown wrote:
| VSCode was essentially unusable for me on large projects.
| We're talking thousands of source files and god knows how
| many node_modules entries. Things like Go to Definition would
| regularly take 15+ seconds! Switched to WebStorm recently and
| have been very happy with the performance.
| lfkdev wrote:
| Weird, i often opened files with hundreds of thousands of
| code lines without any problem. We do have very modern
| Workstations at work though.
| asdajksah2123 wrote:
| VS Code has stopped opening for me for certain codebases.
| And to be honest, these codebases aren't even that large.
|
| I also have 0 extensions installed :(
|
| VS Code used to be my quick and dirty IDE when I didn't
| want to open something heavier, but it's gotten so much
| more painful than even a couple of years ago.
| chii wrote:
| it's quite likely that your issue is with the actual
| node_modules directory being referenced as part of your
| source. It slows the LSP too.
|
| Exclude it (via
| https://code.visualstudio.com/docs/getstarted/settings) by
| using "files.exclude": { "**/.git":
| true, "**/.svn": true, "**/.hg": true,
| "**/CVS": true, "**/.DS_Store": true,
| "**/Thumbs.db": true, "**/node_modules" : true
| }
|
| I've not had any issues with speed ever since i started
| excluding directories that contain junk stuff that you know
| you will not ever need to see in a project's view.
| wongarsu wrote:
| If you have large files (as in hundreds of MB or bigger)
| in your project directory, especially text files, it also
| really pays off to put them into either your .gitignore
| or the files.exclude.
|
| Often happens to me when I run projects that output large
| CSVs, and it's a very notable performance impact.
| Shrezzing wrote:
| >We're talking thousands of source files and god knows how
| many node_modules entries.
|
| I think most VSCode features are disabled for node_modules
| directories by default.
|
| At a guess, I'd say re-disabling that in your workspace
| file would resolve all of your performance issues. For even
| simple projects you'd be including hundreds of MB of text
| files, and thousands of subdirectories.
| bemusedthrow75 wrote:
| They are indeed -- and it will avoid similarly costly
| stuff on anything you .gitignore.
| vbezhenar wrote:
| Today I worked with not-so-large project: 255 typescript
| files, 26K LoC, 920 modules in node_modules, 29351 js/ts
| files total (with node_modules), 4.5M LoC total. I just
| checked and go to definition works pretty much instantly.
|
| Anyway go to definition is a function of LSP server, AFAIU.
| I understand that it's bundled with vscode and feels like a
| single product, but still I'd separate vscode and LSP
| servers and judge them differently.
| sebzim4500 wrote:
| For the most part I agree with you but "miles away of any JS
| apps" is a low bar to cross.
| mrweasel wrote:
| Why is it that VSCode is the only good Electron app? I get
| that Microsoft have talented developers, but so does other
| companies, yet VSCode remain the single application that
| shows that Electron apps can work.
| IceSentry wrote:
| I use discord and gitkraken every day and I've never had
| any issues either. People just like to complain. They act
| as if using a few hundred megabytes for the main app you
| are using is an issue. It's not the 90s anymore ram is
| cheap, especially at those amount.
| 5e92cb50239222b wrote:
| Or maybe you're just fine with throwing away thousands of
| dollars at it every few years, so you're not seeing the
| problem. The "solution" that most of the world simply
| cannot afford.
| wiseowise wrote:
| Of cut it off with most of the world bullshit, we're
| talking about development tool here, not solving world
| hunger.
| whynotminot wrote:
| If I could roll my eyes any harder, they'd be spinning.
|
| 99.9% of people who complain about electron apps are not
| ardent defenders of third world computing. It just
| violates their sensibilities.
| xigoi wrote:
| Why is it better to have a million people buy more RAM,
| creating a large amount of electronic waste and
| emissions, instead of putting some effort into not
| unnecessarily wasting resources?
| EMM_386 wrote:
| > It's not the 90s anymore ram is cheap, especially at
| those amount.
|
| I just wrote the exact same thing in another comment.
|
| That's what the problem is ... it's the old timers
| complaining that things aren't native, thus they are RAM
| hogs and are slow by default. Even if they are fast, they
| are "slow and bloated" just because it's the gut reaction
| when you have layers on layers of other stuff over native
| code.
|
| And I'm an old timer but I am not complaining. I love VS
| Code and I think it's blazing fast for what I need it
| for, a large Angular enterprise application.
| esafak wrote:
| People act as if their precious app is the only one a
| user is going to run and has the right to hog all the
| memory and CPU.
| CharlesW wrote:
| Also, Figma.
| pcthrowaway wrote:
| Obsidian also
| esafak wrote:
| I think WebAssembly might play a role there. https://twit
| ter.com/mattrickard/status/1410714002456383490
| troupo wrote:
| > Why is it that VSCode is the only good Electron app?
|
| Because you need to sink hundreds of thousands of man-
| hours into making it work.
|
| And fight against web tech most of the time you're doing
| that.
| sirwhinesalot wrote:
| Even though it is based on web tech and Electron, VSCode
| cares about performance, while garbage like Microsoft
| Teams does not. That's about it.
| akkad33 wrote:
| I use vs code and jet brains intellij. Vscode is by miles
| more stable and light weight for running a java spring app.
| Of course intellij runs a lot of stuff but the experience
| is not better for it. Intellij feels like a sloth next to
| vscode
| marginalia_nu wrote:
| IntelliJ is not very fast by any benchmark. I mean it's
| based on Swing! There's a pronounced multi-frame pause
| between right clicking and seeing a context menu.
|
| C++ based editors like Kate blow both VSC and IJ out of
| the water. Runs so fast it feels janky, like the computer
| isn't doing anything.
| akkad33 wrote:
| I haven't heard of Kate. I'll try it out
| marginalia_nu wrote:
| It's from the KDE project, and while it's portable, but I
| can't speak for how well it looks on other platforms.
| troupo wrote:
| IntelliJ has a lot of legacy code, including custom re-
| implementation of all things UI.
|
| _And_ it offers vastly more features than VS Code.
| uoaei wrote:
| Yeah this sounds like a misconfiguration. We've already
| forgotten that native apps tend to require a bit more
| fine control on how they use resources, all in the name
| of the cult of portability.
| akkad33 wrote:
| How do I configure it right? One good thing about vs code
| is it works well out of the box with almost zero custom
| configuration
| 5e92cb50239222b wrote:
| It also does maybe a quarter of what IDEA can do. Let's
| see how it performs when it catches up to what IDEA does
| right now (maybe in another ten years).
| akkad33 wrote:
| It does everything I need to run to do my job. If
| intellij is doing more stuff that is slowing it down then
| maybe they can find a better performance-feature trade
| off by getting rid of the bloat
| pcl wrote:
| Make sure you've got your IJ memory settings tuned right.
| I assign 8GB rather than the default (2?).
|
| Also, if you're on a Mac -- there's an Apple Silicon
| build that is noticeably better.
| nickelpro wrote:
| > I assign 8GB rather than the default
|
| This is not a good argument in a thread where the central
| claim is that VSC is a resource hog but other IDEs aren't
| rizky05 wrote:
| [dead]
| fragmede wrote:
| 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.
| vbezhenar wrote:
| Apple M1 Max.
|
| I understand that everyone's situation is different, but I
| live in a poor country, making like $2k/month and still
| consider investments into my computer worthwhile, so I
| never tried to save money on it. This is american website,
| so most people here surely can afford fast computer for
| their work.
| wenc wrote:
| I used to run vim and VS Code on a Core 2 Duo from 2005.
| Vim is a lot faster but VS Code is so much more powerful --
| it's a full featured IDE. It's not a quick and dirty text
| editor like Kate. It's not meant to be that. I still use
| vim to edit config files but for everything else I use VS
| Code.
|
| I've since upgraded to a 2014 i7 and now VS Code feels
| fast.
| CalChris wrote:
| I use VSCode NeoVim and clangd. This has gotten so good,
| although command mode took awhile, that I rarely need to
| use a terminal vim.
| chinaman425 wrote:
| [dead]
| bick_nyers wrote:
| 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.
| zenapollo wrote:
| I'll bet a lot of this whole argument is just windows v
| mac. VS code is snappy on Mac, much less so on my windows
| machine.
| bamfly wrote:
| It's better than other Electron programs (a low bar, since
| most of those perform _shockingly_ poorly) but eats way more
| system resources and performs noticeably worse than Sublime
| Text, on my machine.
| wiseowise wrote:
| Oh noes, who could've thought that application written in
| JavaScript that gets executed on browser engine is slower
| than lean C++ that uses their own custom GUI toolkit
| http://news.ycombinator.com/item?id=2822114.
| VHRanger wrote:
| Sublime text is an editor, VS Code is an IDE, though?
|
| The featuresets aren't the same.
| bamfly wrote:
| I'd say they compete in a similar space of smart plugin-
| friendly code editor, not IDE.
|
| What are you thinking of, in terms of differences? I use
| both quite a bit (some of VSCode's plugins are better)
| and have always viewed them as very close to one another,
| in terms of features.
| tredre3 wrote:
| For one thing VS Code has a full debugger with
| breakpoints and stack analysis that supports many
| backends out of the box, that's an IDE feature.
|
| Sublime doesn't have any (real) debugger even with
| plugins. Some attempt to tack on a debugger but they have
| to do so via popup menus or overloaded "magical" text
| buffers and it's atrocious. Why can't I click on the line
| I want to break on? Why can't I see the stack in a nice
| editable tree? Right, because sublime is a text editor
| and VS Code is an IDE.
| bamfly wrote:
| Ah--I'd never noticed VSCode could do that, in years of
| using it. I ignore some of its features (some of which
| Sublime also has, and I tend to ignore them there, too)
| because I find them janky and fragile or requiring-
| configuration such that I lose a lot of time keeping them
| happy, like any kind of run-from-editor stuff and the
| built-in terminal (it _always_ seems to have a messed-up
| environment or get itself into broken states) dropping to
| a separate terminal for that sort of thing. Not like when
| I 'm, say, working in XCode or Intellij and almost
| exclusively run, build, & debug from inside the IDE,
| rarely touching a separate terminal.
|
| Guess you've got a point, then, and I just don't use it
| that way.
| tibordp wrote:
| That's interesting, I don't find VSCode slow at all, even when
| working on large workspaces via SSH over a high latency link.
|
| Sure, there are native editors that are snappier, but not to
| the point that affect my productivity in any way.
|
| The one thing that VSCode does not handle well is large files
| (e.g. DB dumps, large JSONs, logfiles), but for coding, it
| really is not an issue.
| kayodelycaon wrote:
| As a rather vocal user of Sublime Text 4, VS Code is an order
| of magnitude slower on basic UI interaction.
|
| I eventually switched to VS Code but I miss immediate
| highlighting and extremely fast start times. It's very close
| to TextEdit launch speeds. VS Code crawls by comparison.
|
| The only reason I'm using VS Code is the plugin system is way
| better.
| luckman212 wrote:
| What plugin are you using to open workspaces via SSH?
| singlow wrote:
| There is a Microsoft-built plugin called Remote - SSH,
| which fits into a group called "Remote Development" that
| includes WSL and Docker versions. It basically runs most of
| vscode on the remote, and feels just as fast as local on a
| decent connection. Most of the heavy lifting is done on the
| remote so things like full project searches, or linting,
| etc not having to go through ssh to access the files.
|
| I use it for almost all of my development. I launch an ec2
| instance with my projects and all of my code and data stays
| in my dev vpc. I can connect from my laptop or workstation
| and I can spin up extra dev environments if I am working on
| multiple projects. Plus, since the projects usually involve
| a pretty big data set, i don't have to download that
| locally and it can be replicated quickly within the vpc for
| each dev environment.
|
| The SSH extension even knows how to forward ports back and
| you can add/remove port forwards from the vscode ui.
| arijun wrote:
| They are probably using "Remote - SSH" by the VSCode team.
| It was a big part of what convinced me to switch from
| Pycharm. That and being able to work on C++ code from the
| same tool.
| tibordp wrote:
| Just the standard Remote-SSH
|
| https://code.visualstudio.com/docs/remote/ssh
| reaperducer wrote:
| _VSCode is a good tool, but it's unbearably slow_
|
| The funny thing is that the reason I and many other people
| switched to VSCode is that it used to be so speedy.
|
| I sometimes wonder how much of its decrease in speed over the
| last few years is due to feature bloat (which it seems to have
| in spades) and relying on hobbyists, who have less incentive to
| optimize, to fill out the plug-in ecosystem.
|
| I moved my personal projects to Nova, and it's screamingly
| fast. But I still have to use VS for work, and even though I
| only have four plug-ins, the difference is like pouring water,
| versus pouring honey.
| IceSentry wrote:
| If vscode slowed down for you it might mean you installed too
| many extensions.
|
| Personally it feels just as fast or faster than before.
| Especially with things like the mentioned bracket colorizer
| beinf built in compared to the extension I was previously
| using.
| ukFxqnLa2sBSBf6 wrote:
| VSCode is slow at... what? Is your computer from the 90s?
| zdragnar wrote:
| The slowness that I've observed almost always comes from the
| language servers. The rest really isn't much worse, if at all,
| than something like emacs.
|
| I do keep looking for lighter options, but have yet to find one
| that actually does all the things I want. Vim and emacs are
| okay, but getting the right plugins to get the right features I
| want is a pain. Other options seem to lack the ability to add
| those features at all.
| wudangmonk wrote:
| Language servers are slow. Nobody could have predicted this
| since on paper json for process to process communication
| seems like a very sound choice, if the geniuses at microsoft
| could not solve such a difficult problem then surely this was
| the best option out of all the potential bad ones.
| noselasd wrote:
| Make it work, then make it fast is in most cases what you
| should do.
|
| I've done almost all development in vim up till 3-4 years ago
| before switching to vscode. It's more than fast enough for me.
| Zetice wrote:
| Everyone should do a stint coding in vim, you learn so much
| about the things an IDE hides from you, and your terminal
| skills grow exponentially.
| flohofwoe wrote:
| 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.
| eikenberry wrote:
| 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.
| TheLoafOfBread wrote:
| Now imagine that you are doing a development on embedded
| platform - To the compilation time you will add time to load
| the application and time to boot it up.
| Barrin92 wrote:
| compared to what? VsCode is slower than vim without plugins,
| but it's not slower than anything that has feature parity.
| VsCode is closer in functionality to an IDE than it is to a
| text editor, and in that context it is very snappy.
| rusl1 wrote:
| Guys you should buy yourself a good MacBook because VSCode is
| damn good and fast on MacBooks
| nielsbot wrote:
| 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
|
| https://github.com/microsoft/vscode/issues/85587
| jokoon wrote:
| 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.
| speedgoose wrote:
| 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.
| tredre3 wrote:
| I 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.
| tomcatfish wrote:
| 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.
| bluSCALE4 wrote:
| I read it as extension developers will never be able to match
| core since their api is limited.
| mynameisvlad wrote:
| I 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 is available if a
| developer wanted to contribute something to core, anyway.
| omazurov wrote:
| 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.
| compiler-guy wrote:
| The 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.
| XCSme wrote:
| What 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 wrote:
| You 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 wrote:
| I 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 wrote:
| I 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.
| RektBoy wrote:
| 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.
| rafaelturk wrote:
| Such an awesome article to read.. how something `simple` can be
| extremely challenging to execute
| taeric wrote:
| 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?
| bagacrap wrote:
| 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.
| butz wrote:
| 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?
| syngrog66 wrote:
| I specialize in software perf & scalability, so read nearly
| everything I can on the subject, especially concrete cases like
| this!
| akasakahakada wrote:
| But 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
| ghnws wrote:
| This is not micro optimization. This is fixing a known
| performance issue.
| tiku wrote:
| I get scolded for to many ifs haha.
| bick_nyers wrote:
| I'll take verbose code over code golf any day.
| practal wrote:
| 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.
| Narishma wrote:
| Do people really like this type of syntax highlighting? The
| screenshots in the article to me are a hard to read color soup.
| kortex wrote:
| I'm a big fan. My source code looks like a rave. I think it
| depends on your neurotype quite a bit though.
| awestroke wrote:
| Yep, it's great
| yoyohello13 wrote:
| Yeah, I find the 'every symbol has a color' highlighting to be
| difficult to parse.
|
| When everything is colorful, nothing stands out.
| cubefox wrote:
| It's very useful when trying to find matching brackets in code!
| akamoonknight wrote:
| In 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?
| tredre3 wrote:
| > In just basic Vim, there's highlighting such that if the
| cursor is over a start bracket (or end bracket), the
| opposite bracket is highlighted.
|
| VS Code does that too and I think that's plenty to find
| matching brackets.
|
| Never understood colored brackets either, it looks like a
| noisy rainbow to me. But I think it might depend on the
| language+theme combination you're using.
| cubefox wrote:
| I 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 wrote:
| Gotchagotcha, so yeah, to some extent eliminates the time
| taken to highlight individual brackets at the cost of
| adding some visual complexity. Thanks.
| frankreyes wrote:
| Monolith vs micro kernels, next round.
| robertoandred wrote:
| Cool, maybe now they can add native titlebar functionality that
| real document apps have?
___________________________________________________________________
(page generated 2023-06-22 23:02 UTC)