> Sometimes I think it would be nice to have limits on resources in order to more automatically find mistakes like this
I was actually fairly disappointed when Visual Studio (not code) went to 64-bit. Because I knew its memory usage was now going to be unconstrained. Still way better than the unapologetic gluttony of Rider but experiences showed it to be a bit leaky over time (tip: Ctrl-Alt-Shift-F12 twice does a full garbage collection https://learn.microsoft.com/en-us/visualstudio/ide/visual-st...)
Also remember that all your references (pointers) are going to double in size so right off the bat it will use more, potentially a lot more depending on how reference-heavy your data is
Even if it stayed 32 bit that wouldn't have helped with memory resources, because experience has proven that if we care about host stability extensions should be running on their own processes with OS IPC.
Which is something that VSCode does, and VS has been increasingly adopting, and I bet VS 2026 will most likely double down on it.
Which in the end means lots of processes going around to support IDE related tasks.
I was actually fairly disappointed when Visual Studio (not code) went to 64-bit. Because I knew its memory usage was now going to be unconstrained. Still way better than the unapologetic gluttony of Rider but experiences showed it to be a bit leaky over time (tip: Ctrl-Alt-Shift-F12 twice does a full garbage collection https://learn.microsoft.com/en-us/visualstudio/ide/visual-st...)
Also remember that all your references (pointers) are going to double in size so right off the bat it will use more, potentially a lot more depending on how reference-heavy your data is