Live data from Hacker News

Severe performance penalty found in VSCode rendering loop

github.com

21–30 of 46 posts

Re: Severe performance penalty found in VSCode rendering loop

#21

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.

Re: Severe performance penalty found in VSCode rendering loop

#22
post #7
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.

Even if it is a real performance issue, the reasonable fix would be to move the sort call out of the loop - implementing a new data structure in JS is absolutely not the way to fix this.

There’s clearly functionality to push more work to the current window’s queue, so I would not be surprised if the data structure needs to be continually kept sorted.

(Somewhere in the pile of VSCode dependencies you’d think there’d be a generic heap data structure though)

Re: Severe performance penalty found in VSCode rendering loop

#23
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?

https://www.electronjs.org/docs/latest/tutorial/performance

Re: Severe performance penalty found in VSCode rendering loop

#24
post #13

> Real-world impact: With 50+ view parts (text, cursors, minimap, scrollbar, widgets, decorations, etc.), this wastes 1-2ms per frame Good thing to find...

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

it's sorting 50 times a list going from 50 to 0 items.

Re: Severe performance penalty found in VSCode rendering loop

#25
If you work with LLM agents, you will immediately be able to tell this issue is written by one. The time cost of this sort is almost certainly not real, as others have pointed out.

I’ve had agents find similar “performance bottlenecks” that are indeed BS.

Re: Severe performance penalty found in VSCode rendering loop

#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 documentation.

Re: Severe performance penalty found in VSCode rendering loop

#27
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.

i see emojis in the comments.

also no discussion of measured runtimes for the rendering code. (if it saves ~1.3ms that sounds cool, but how many ms is that from going over the supposed 16ms budget.)

Re: Severe performance penalty found in VSCode rendering loop

#28

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.

bugman

Re: Severe performance penalty found in VSCode rendering loop

#30
post #13

> Real-world impact: With 50+ view parts (text, cursors, minimap, scrollbar, widgets, decorations, etc.), this wastes 1-2ms per frame Good thing to find...

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

The issue seems to be a direct copy-paste from an LLM response, so I suspect "this wastes 1-2ms per frame" is estimated/made up.
Post reply on HN