4 ms·
You can trace a lot of these problems to their bone-headed decision about a decade ago where they refused to see where things were going and kept rationalizing
by thrower123 5y ago
You can trace a lot of these problems to their bone-headed decision about a decade ago where they refused to see where things were going and kept rationalizing not moving to 64-bits.
I have some moderately sized solutions that take forever to open and chug to a halt and start paging like crazy with unresponsive UI if I don't disable all the code inspections and Intellisense. This is on a brand-new i7 with 32GB of RAM and a NVME SSD. It pegs itself at that 32-bit process memory limit and thrashes. It's worse if it is a modern web app with a bunch of JS involved.
And so I've used Rider almost exclusively for the past fifteen months or so...
- rk06 5y agoFWIW, vs2022 is 64bit.
- foepys 5y agoAnd they promptly shot themselves in the foot with it as you now need 64bit components for their form designers, even if you exclusively build 32bit apps. If you maintain an application with legacy form components that are only available in 32bit, you now need to continue using VS2019. Granted, who builds 32bit in year 2022 but VS claims to support 32bit, which it actually doesn't fully. There is still a chance that they will fix this before release but I highly doubt it.
- liversage 5y agoPerhaps that's one of the reasons they have didn't switch to 64 bits earlier? If the IDE is a 64 bit process it can only render external components at design time if they are 64 bits. To be able to render 32 bit components at design time they would need to be hosted in another 32 bit process. I can see how that feature would be complicated and expensive to develop.