Severe performance penalty found in VSCode rendering loop
1–10 of 46 posts
Re: Severe performance penalty found in VSCode rendering loop
#2A bit sloppy but easily resolved - surprised it took so long to notice, or maybe it was new?
Re: Severe performance penalty found in VSCode rendering loop
#3Given 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.
Re: Severe performance penalty found in VSCode rendering loop
#4> Real-world impact: With 50+ view parts (text, cursors, minimap, scrollbar, widgets, decorations, etc.), this wastes 1-2ms per frame
Good thing to find...
Re: Severe performance penalty found in VSCode rendering loop
#5Looks interesting.
I see they also contributed a fix to the OnlyFans notification robot. Clearly doing the important work that the internet needs.
Re: Severe performance penalty found in VSCode rendering loop
#6I'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.
Re: Severe performance penalty found in VSCode rendering loop
#7Given 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.
Re: Severe performance penalty found in VSCode rendering loop
#8This seems like a nonsense issue. Sorting 50 things takes 1-2 ms? What sort of potato was that timed on.
Re: Severe performance penalty found in VSCode rendering loop
#9Given 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’ve already moved from
VSCode to Zed. It’s native. Faster. Has most of the functionality I had before. I’m a huge fan.
Re: Severe performance penalty found in VSCode rendering loop
#10Given 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.
Right, and also this would show up in the profiler if it were a time sink — and I'm 100% certain this code has been profiled in the 10 years it's been in the codebase.