Hacker News Reader

Comment by antaviana | Hacker News Reader

Rico Mariani, the "perf guy" at Microsoft, had this opinion on VS 64-bit in 2009:

https://web.archive.org/web/20160309232651/http://blogs.msdn...

It’s easy to rationalize yourself into this kind of opinion when you know there would be a monumental amount of work to get to 64 bit. I know this blogger is respected and the post influential, but that doesn’t make him right. Notably absent in his post is any kind of benchmark or data to support his opinion.

Meanwhile, are there any examples of modern applications being written in 32 bit for performance reasons? Not that I can think of, or at least nothing that is meant to run on a 64 bit PC.

There’s a lot you can do with extra memory headroom, especially when developers usually have 16 or 32 GB to work with.

Generally performance gets better mostly because x64 arch has more registers.

That being said, I really wish the X32 ABI in linux had garnered more interest. The concept is that it's 64-bit code that runs with a 32-bit memory space. All your pointers can still be 32 bits but you also get all the architectural advantages of 64-bit mode too. In theory you should get the perf benefits of 64-bit without the perf costs.

The ABI wasn't really used much, so it got removed. But it was a bit self fullfilling. We never wanted to switch to it because it had poor surport from distributions, but distributions didn't bother supporting it because nobody used it!

This was a stupid take even then.

Performance in Visual Studio has become such a problem that I've renounced it entirely in favor of Rider.

This is where I am, too - long time .NET dev, have gotten increasingly frustrated with Visual Studio's awful performance, especially with ReSharper. I've tried taking that out given VS has a bunch of that stuff built in, but working without R# completions feels like trying to work with one arm tied behind my back.

Between that and my preference for Macs for my personal laptops -- and I've been very excited at how good .NET Core has gotten on non-Windows platforms -- as well as a ~3 year sojourn working with Java 8/11 in IntelliJ, I've gotten very comfortable working with JetBrains IDEs and generally prefer them when I have the option. Structure View is great, the search is nice and snappy.

The only thing that frustrates me with Rider is I don't think you can apply fixes from Roslyn analyzers at the file/project/solution level like you can in VS. We enforce our team's coding standards using those, so it's a minor pain point, but not enough to get me to stop using Rider given how much faster it is.

Having worked mostly on solutions with at least one Web project in the mix, it's even worse. I absolutely love VS Code, but VS itself is a beast that I just avoid opening if I can at all avoid it.

VS Code isn't quite as good on C# projects, I will admit, but still so much better (less blocking) in general.

Not familiar with Rider though.

So basically, if you need more than 4G it's your problem cause you're doing it wrong.

What a horrible thing to say to your customers.

the example in the 2022 announcement was a project with "1,600 projects and ~300k files", which maxes out at around 5GB. How many users actually experience this?

Sadly me and many others in large corporate environments. Not quite that bad but still pretty bad.

My advice to people is to consolidate projects wherever possible, although you wouldn't know it seeing some project layouts you can still have separate namespaces and folders inside projects. I think many do this in the hope it will help build times but it does the opposite, msbuild is the slow part and csc (the c# compiler) is lightning fast, so make it do the heavy lifting.

Yeah, if your projects are so tightly coupled that you have to work on them in the same Solution, then you may as well Join them most of the time.

Another bit, I would generally have the Interfaces project include the client... so one DLL for other solutions to import from, and it doesn't really add much of anything to the Server implementation. That's just one example.

Another is separating API controllers, DAL, BLL into separate Projects... there's rarely a practical reason for this, and in practice just adds indirection and complexity for very little real world value. But hey, "Enterprise" patterns and all.

I think that’s an incorrect restatement of his view. I think what he is saying is that if Visual Studio is using too much memory then the problem is with visual studio and that it makes much more sense for the VS team to spend time and energy on retooling algorithms and data structures used in VS code to use up less memory than spending that time converting it to 64 bit.

Reply on news.ycombinator.com