I think it's largely a dog fooding problem. Visual Studio is a superb piece of software, and you can tell that its designers are the primary users. Microsoft's consumer apps are awful.
That's fair (re: 64-bit) and I'll amend: VS2015 should be able to handle a solution with (say) 1,000 projects without crashing. If that can be done in 32 bits, hurrah.
its not that uncommon to find VS solution files consisting of 100+ projects, especially in finance. The most I've worked on was 132 projects in a single solution (roughly a third were test projects). It was slow and sluggish at times but still workable nevertheless...
Wow, I'm impressed! What do you work on where 1,000 projects in a solution is a thing? With just one developer per five projects you've got a team of 200 developers. What are you working on? Please give us a few details.
I'm working on a legacy desktop app (~25 years), currently around 600 projects. Maybe one developer per 7 projects. Common workflow is to create custom solutions around your working set of projects, but that's not ideal for whole code analysis/debugging.
Does that mean that there's a lot of duplicate projects? It seems like there's an opportunity for consolidation. I've seen a few solutions where a developer created a Project for every class library and then only ever referenced them from 1 other Project. I was able to roll up a 30+ project solution into 5.
We had ~150 projects across about 1M LOC and 4 developers because they were being used like folders - they weren't really separate codebases, just a means of organising the code. We cut that down for a drastic improvement in speed.
Most "serious" users are now uninstalling ReSharper. Visual Studio 2015 adds most of ReSharper's key perks and JetBrains has done little or nothing to resolve ReSharper's laggy/hoggy/unstable code (and has said they aren't going to re-write it for Roslyn).
Honestly back in VS 2010 I'd call ReSharper a core tool. In VS 2015, eww.
I've never liked ReSharper, have felt that the "advice" it offers is often over-rated and seems commonly to be wrong for C# (not unexpected given that JetBrains primarily focuses on Java outside of ReSharper, I feel like ReSharper is a Java developer's approach to C#). These days what's baked into VS and the Roslyn compiler platform blows ReSharper out of the water.
Just about everyone I've worked with that had daily complaints about how slow and laggy they felt Visual Studio was didn't seem to understand that ReSharper was 99% of the slow-down, excessive memory use, and UX lag...
I never liked it either, but I've worked in places where it was like the eleventh commandment and you better not say anything against it! :) I'm glad to hear it's loosing popularity.
Not moving to 64 bit has been a pragmatic decision [1]. As for crashing, I used it for over 10 years at my previous company and it never crashed once. At my current company it only crashes when I am using the Stylevision plug-in, which is really, really, buggy.
That pragmatic decision was made 7 years ago. A lot has changed since then and I don't think the arguments hold up. What developer machine doesn't have at least 16 GB of RAM these days?
Thanks for posting that (although I didn't see any benchmarks).
My big problem with the first article was that in my experience, the extra registers available in 64-bit make all the difference in the world. In the comments for the article you posted, he says that isn't true with VS. Surprising, but I'll take his word for it.
Still, it bothers me that he keeps talking about 4 GB of code and data should be enough. VS becomes pretty unusable for me around 1.5 - 2 GB. If it worked reliably up to the 4 GB limit, I'd be happier.
The limit is usually address space fragmentation and at one point not being able to find a piece of memory large enough for an allocation. Depending on the allocation patterns this may happen around 3 GiB but for some applications even around 1.7 GiB already. VS gets unbearably slow around 2 GiB memory, though, most likely because the native allocator has to piece together all free pieces of memory again and in the managed part the GC probably has fun trying to compact memory.
Did you even read the article? The arguments still hold up. It's clearly the case that it's not worth the effort to move VS to 64-bit.
- "First, from a performance perspective the pointers get larger, so data structures get larger, and the processor cache stays the same size. That basically results in a raw speed hit..."
- "The cost of a full port [due to the amount of code involved, not the quality of the code] of that much native code is going to be quite high and of course all known extensions would break and we’d basically have to create a 64 bit ecosystem pretty much like you do for drivers. Ouch."
- "A 64 bit address space for the process isn’t going to help you with page faults except in maybe indirect ways, and it will definitely hurt you in direct ways because your data is bigger...32 bit processes accrue all these benefits just as surely as 64 bit ones."
OK then let's compare VS to XCode, which doesn't even have half the features of VS and crashes twice as much. If not, which comparable product would you pick?
Running tons and tons of VS instances while debugging broken, memory hogging programs, modifying the XML for weird project types for third party plugins poorly, etc. Things that MS really can't do anything about.
I would have agreed that it's a good product right up to Visual Studio 2013. But Visual Studio 2015 is slow, buggy and unstable. They really have screwed something up, it has been months, and the update pack they released didn't make any tangible improvements. Meanwhile the "extensions and updates" area just continues to push Microsoft products I don't need, and every now and then I am not allowed into the IDE because my license has "gone stale". Everyone in my team has daily crashes, bugs and slowdowns and it is hurting us. How can Microsoft not have found any of these issues during all their testing?
I've been using various versions of Visual Studio since 1999. I can count on one hand the number of times it has crashed, usually coincident with me doing something unwise.
Most things in VS run in-process (that was the case circa mid-2000s, at least). It only takes one bad component to bring the whole thing down, and there are many, many, many components.
IME, Visual Studio crashes are almost always due to misbehaving plugins. I'm in it all day every day, and once or twice a week it will develop some quirk that requires a restart to fix, but I can't remember the last time it actually crashed. The only plugins I run are Resharper, Xamarin, and PTVS.
Funny though that Visual Studio insists on defaulting to upper case menus. That must be a decision forced on them by a PHB somewhere, which just tells you that nobody is immune from the organizational rot.
Oh, I positively lurve the Microsoft design team's justification for all caps:
When we shared the RC design preview with you, we expected the uppercase menu would generate mixed feedback and emotions. We had seen similar reactions from early adopters and from our own internal users prior to posting about it. [1]
So then they said they had been "thinking about it" (why a lot of thinking was necessary is beyond me), and that "using uppercase for the menus was not an arbitrary decision" because they needed "to keep Visual Studio consistent with the direction of other Microsoft user experiences".
Then they tried to say that "some of you" won't like the change and that these people have "been very direct in expressing your opinions on this subject".
In other words: they got told it was an absolutely awful decision from the very start by beta testers and their own test team, but ignored it because, well, "consistency". Then they released it and they got almost total user revolt, but they can't back out now because, well, "consistency". But they now allow you to change to letter case with a registry tweak, after all - Microsoft know better than their end users, even when those end users are screaming for them to change a fairly fundamental UX error.
