Severe performance penalty found in VSCode rendering loop (github.com)

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

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.

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

Good thing to find...

Looks interesting.

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

I'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.

This seems like a nonsense issue. Sorting 50 things takes 1-2 ms? What sort of potato was that timed on.

The penalty is called "Electron".

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?

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.

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.

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.