This seems like a nonsense issue. Sorting 50 things takes 1-2 ms? What sort of potato was that timed on.
No, sorting 50/2ish things 50 times allegedly takes 1-2ms. Which is only slightly more believable.
Severe performance penalty found in VSCode rendering loop
11–20 of 46 posts
Re: Severe performance penalty found in VSCode rendering loop
#12I'm confused: Does top.execute() modify currentQueue in some way, like pushing new elements to it? If it doesn't, then why not simply move the sort out of the loop? This is simpler and faster than maintaining a binary heap.
One more thing: Nowadays sort() functions ary usually heavily optimized and recognize already sorted subsequences. If currentQueue isn't modified during the loop, then the sort() call should run in O(n) after the first iteration, instead of O(n * log n). Still worse than not having it inside the loop at all, of course.
Re: Severe performance penalty found in VSCode rendering loop
#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
Re: Severe performance penalty found in VSCode rendering loop
#14Given 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
Re: Severe performance penalty found in VSCode rendering loop
#15The penalty is called "Electron".
Re: Severe performance penalty found in VSCode rendering loop
#16> 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 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.
Re: Severe performance penalty found in VSCode rendering loop
#17Given 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.
Yeah the issue reads as if someone asked Claude Code "find the most serious performance issue in the VSCode rendering loop" and then copied the response directly into GitHub (without profiling or testing anything).
Re: Severe performance penalty found in VSCode rendering loop
#18I'm confused: Does top.execute() modify currentQueue in some way, like pushing new elements to it? If it doesn't, then why not simply move the sort out of the loop? This is simpler and faster than maintaining a binary heap.
> If it doesn't, then why not simply move the sort out of the loop?
Yup, they should definitely move the sort outside of the loop. Shifting is O(N) so overall complexity would be O(N^2) but they could avoid shifting by reverse-sorting outside the loop and then iterating backwards using pop()
Re: Severe performance penalty found in VSCode rendering loop
#19I 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?
Re: Severe performance penalty found in VSCode rendering loop
#20Given 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.
Adding a new data structure just for this feels like such an AI thing. I've added to our agents.md a rule to prefer using existing libraries and types, otherwise Gemini will just happily generate things like this.