|
|
|
|
|
|
by temac
1633 days ago
|
|
|
> 64-bit solves so many perf and user-perceived reliability issues I love how in tech everything is always evil one day and the next one nearly the panacea. Now I understand the timing component is actually not to get rid of entirely, in the sense that maybe a 64-bit VS would have been a bad idea the year AMD released x64, but among the stated reasons to stick to 32-bits not so long ago, and even one of the main, there was: performance. I suspect the cold reality was that the code base was not ready and the migration just took some time :) |
|
|
Yeah, this was from a series of articles that were a great example of managing to be right about all kinds of things but still be wrong in the end.
Specifically, the articles laid the blame for things like memory usage (which when high enough, causes a foreground GC in the devenv.exe process that freezes your UI), on language services that get all too happy to allocate tons of memory. If you make this 64-bit, pointers double in size and you could observe even more memory usage. 64-bit is also objectively slower than 32-bit in terms of CPU time to execute stuff. The solution it suggested was for memory-intensive components to move out of process, which is actually what many of them did in VS 2017 and VS 2019.
But the problem with this article is that it was entirely speculation. It did not account for several things:
* A 64-bit devenv.exe process gives the GC more "room to work with" and do more background GCs rather than foreground GCs, which will pause the UI far less
* Marshaling data between processes still requires use of the UI thread in VS in various scenarios, due to a wildly complicated threading model that people mess up all the time
* You really don't know what the impact of something is going to be until you actually do it
* If you commit to something ambitious like going 64-bit only, engineers can meet the challenge and produce something very good
My personal belief is that 64-bit could have been reasonably accomplished many years ago, and it would have been the right call to do it then. But I won't be looking a gift horse in the mouth. The codebase I contribute to is so much more pleasant to work in with VS 2022.