Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Severe performance penalty found in VSCode rendering loop

github.com

Post reply on HN
Print view View original

31–40 of 46 posts

Re: Severe performance penalty found in VSCode rendering loop

#31

Post by nawgz »

geokon wrote: post #19

I feel with Valgrind (in C++land) or VisualVM (JVMland) stuff like this is very easy to zero in on. I don't work in JS-land.. but are Electron apps difficult to do performance profiling on?

No. Browser dev tools are available, and make it pretty easy to do performance profiling, and get a flamegraph etc..

Just seems like the reality of things is that the number of extensions or widgets or whatever has remained low enough that this extra sorting isn't actually that punitive in most real-world use cases. As a long-time developer working mainly in VSCode, I notice no difference between performance/snappiness in VSCode compared to JetBrains Rider, which is the main other IDE I have meaningful experience with these days.

Re: Severe performance penalty found in VSCode rendering loop

#32

Post by anticensor »

webprofusion wrote: post #5

Looks interesting. I see they also contributed a fix to the OnlyFans notification robot. Clearly doing the important work that the internet needs.

That notification robot codebase is actually generic, Zara Darcy just used OnlyFans branding to boost her follower base.

Re: Severe performance penalty found in VSCode rendering loop

#33

Post by anticensor »

minitech wrote: post #29
nawgz wrote: post #2

A bit sloppy but easily resolved - surprised it took so long to notice, or maybe it was new?

It’s been around since the root commit in 2015: https://github.com/microsoft/vscode/blob/8f35cc4768393b25468...

Yeah, it was a bit surprising to me as well.

Re: Severe performance penalty found in VSCode rendering loop

#34

Post by anticensor »

sillythrowawy9 wrote: post #14
muglug wrote: post #3

Given that the issue already gives a before-and-after metric it's extremely odd there's no POC PR attached. This just seems like an AI slop GitHub issue from beginning to end. And I'd be very surprised if VS Code performance could be boosted that much by a supposedly trivial fix.

OP’s account also seems automated. This certainly feel like automated post to social media for PR clout

Not really, I read HN more than I post to it, but I found this one interesting.

Re: Severe performance penalty found in VSCode rendering loop

#35

Post by duskwuff »

klodolph wrote: post #16
blharr wrote: post #13

Earlier quoted context omitted.

How does it possibly take 1-2ms to sort... 50 items? I'd expect that to happen in an order of microseconds

It’s being sorted not once per frame, but once per item . If you have 50 items in the list, then the list gets sorted 50 times. If you have 200 items in the list, the list is sorted 200 times. This is unnecessary. The obvious alternative is a binary heap… which is what the fix does. Although it would also be obvious to reuse an existing binary heap implementation, rather than inventing your own.

> It’s being sorted not once per frame, but once per item.

Even if that were the case, sorting a list that's already sorted is basically free. Any reasonable sort method (like the builtin one in a JS runtime) will check for that before doing anything to the list.

> The obvious alternative is a binary heap… which is what the fix does.

The overhead of creating a heap structure out of JS objects will dwarf any possible benefit of avoiding a couple of calls to Array.sort().

Re: Severe performance penalty found in VSCode rendering loop

#36

Post by anticensor »

klodolph wrote: post #16
blharr wrote: post #13

Earlier quoted context omitted.

How does it possibly take 1-2ms to sort... 50 items? I'd expect that to happen in an order of microseconds

It’s being sorted not once per frame, but once per item . If you have 50 items in the list, then the list gets sorted 50 times. If you have 200 items in the list, the list is sorted 200 times. This is unnecessary. The obvious alternative is a binary heap… which is what the fix does. Although it would also be obvious to reuse an existing binary heap implementation, rather than inventing your own.

> Although it would also be obvious to reuse an existing binary heap implementation, rather than inventing your own.

Yes, that's indeed the approach I'd take.

Re: Severe performance penalty found in VSCode rendering loop

#37

Post by OrderlyTiamat »

brokencode wrote: post #21
webprofusion wrote: post #5

Looks interesting. I see they also contributed a fix to the OnlyFans notification robot. Clearly doing the important work that the internet needs.

This is what I want to do when I retire. Maybe not OnlyFans fixes specifically, but just go around fixing random stuff. Like if Batman turned out to be bad at fighting criminals so had to fight null pointer exceptions instead.

"Fear not the bugs citizen! For in my utility belt, I have REGEX and VIM!"

Re: Severe performance penalty found in VSCode rendering loop

#38

Post by flowerthoughts »

I would have expected V8 sort() to be optimized for runs of presorted input, like other implementations nowadays. So O(n²) seems more likely than O(n² log n). Not that it matters much.

But then again, probably AI slop with "performance gain" numbers taken out of thin air. Who knows if the number 50 and 1-2ms are based on fantasy novels or not.

Like when I used Claude to build a door video intercom sytem, and first asked it to create a plan. It inserted how many weeks each milestone would take, and it was an order of magnitude off. But I guess milestone documents have time estimates, so that's how it's supposed to look, information accuracy be damned.

Re: Severe performance penalty found in VSCode rendering loop

#39

Post by dkdcio »

ec109685 wrote: post #26

I hate ai sometimes — an AI generated pull request (really some rando found a way of shaving 12% off the run loop?) responded to by an ai comment bot: > This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentatio…

reasonably confident that’s just an automated response bot, not AI…

also it’s an issue, not a PR

Re: Severe performance penalty found in VSCode rendering loop

#40

Post by nurettin »

brokencode wrote: post #21
webprofusion wrote: post #5

Looks interesting. I see they also contributed a fix to the OnlyFans notification robot. Clearly doing the important work that the internet needs.

This is what I want to do when I retire. Maybe not OnlyFans fixes specifically, but just go around fixing random stuff. Like if Batman turned out to be bad at fighting criminals so had to fight null pointer exceptions instead.

Maybe hack into facilities, optimize their scripts and deployment, then leave without a trace confusing the IT department.
Post reply on HN