I only just got my brand new VS2013 set up and I opened up my main project for some tinkering with the IDE. My first impression was that while the editor is certainly easier to customize, looks better and provides more features, it is also unbelievably sluggish compared to 2010. Beginning a block comment sometimes takes 2+ seconds to alter the commented out text. Opening glew.h (15k lines) takes several seconds before I can interact with it and even then scrolling is incredibly slow and uneven. What really dumbfounded me, however, was intellisense's behavior.

I'm not sure whether it is the built-in intellisense or VAX that is causing this, but it stops happening when I disabled either one of them. Namely, I had an ad-hoc member variable __bDirty which, when auto-completed via the intellisense's pop-up list, wouldn't be inserted into the code editor. I had no idea why that was the case until I hand-typed it in and ran build. As it turned out, the name __bDirty had indeed been inserted, but at the very top of the file. So I thought "fine, names starting with underscores are reserved and screw up intellisense or something". I refactored it to something more standard, eg bDirty, but lo and behold - it still behaves the same way. I love VAX and as mentioned above, the name is inserted properly when I disable the built-in intellisense (as in, completely). So I did that.

But guess what - when you disable the built-in intellisense, you also lose any automatic functionality in the peek window! It starts behaving like the default Find prompt:if you peek a variable named stack, it simply lists all known declarations of variables named stack, regardless of what type they are or what class they belong to - and if the header file isn't added to the project, that particular declaration won't even appear in the list.

Now, my IDE is presumably fully up to date (12.0.30723.00 Update 3) and by now the dev team has had plenty of time to patch it left and right. But considering the frankly astonishing sluggishness of the editor, which I specifically read had been addressed and would be far less palpable than in 2012, which I skipped over, I feel like a complete idiot.

Now, to be fair, the misplaced auto-complete string seems like a conflict between both VS and VAX and it's hard to place blame here. I've been a long time VAX user on 2010 and since I would need to purchase a new license anyway, I intentionally got the latest trial version (10.8.2043.0) to try it out so I could see how polished the experience was. But this auto-complete thing ain't a small bug. It's one of those giant brain-sucking bugs from Starship Troopers, and the fact after all this time something like that still crops up, is quite honestly ridiculous.

Anyway - just to be sure: have I missed some update or patch or something or is the sluggish behavior really normal? I've tinkered with enabling and disabling GPU acceleration in the IDE properties, but I'm still having major problems scrolling in files that are any larger than a few thousand lines.

VS2013 with VAX runs lightning fast for me on a 3MLOC codebase. Will it outperform VS2010? No, not on the same machine, but consider that 2010 is 4 years ago. Hardware, particularly in the memory hierarchy front, is significantly better today. I suspect your problem is simply that you're operating on (relatively) incomparable hardware.

I've heard the same complaints about VS2010 related to VS2008. I'm pretty sure I've heard the same thing relating 2008 to 2005. There's probably some loonie out there gloating about how VC6 was so much faster than all the newfangled bloatware.

In case I sound condescending (and I probably do), I'm not aware of any obvious extraneous causes for what you're seeing outside the hardware front.

Runs fast and responsive for me.

Just using Update 2 here, Update 3 broke some aspects of initializer list syntax so I've avoided it.

My PC : i7 4770k

I work on a VM slice on some sort of blade system. I don't think I'm given a big chunk of resources, certainly not GPU-wise. I find VS2013 actually runs very nicely... I don't find it annoying me. I found the same when I tried out 2010 for a few things, but we just migrated from 2005 -> 2013 which is a BIG jump so I was pretty pleasantly surprised.

I only just recently upgraded my coding laptop and I'd say it's relatively decent. i3 (2+2 cores) with 4 GB RAM and nVidia 760M - it's certainly faster than my previous laptop from the same series, although it packs less RAM.

Anyways - I've clocked in some additional coding time on 2013 and while I'm slowly getting used to some of the smaller idiosyncrasies, there are still certain things that are somewhat jarring in terms of behavior. The glew.h issue is still there (very poor handling of large files), though that's mitigated by the fact that in practice I don't really have to deal with files that large. The more annoying issue here is when block commenting out sections of code - there's an immediate response from the IDE, which hilights certain words (as far as I can tell function and variable names), but the block isn't greyed out as expected until 1-3 seconds later. This may not seem like a big deal, but it does interrupt the work flow while your brain tries to figure out precisely which keys it should press next.

So far I haven't encountered any further intellisense hiccups. Though at the end of the day, the IDE is less fluid than 2010, which - while expected -, shouldn't really be a given.

I'm loving the customizable indentation settings, however - these make a world of difference to me, since there was no way to configure 2010 to format code the way I like.

2008 was the last 'fast and responsive' version that I've used, and I work on multiple machines with modern hardware. The slowest machine on my lineup is a Q6600 w/ 8GB, which should be more than enough for a fast IDE.

I just pulled up a project that still has autogenerated vcproj files. About 13 seconds to load on VS2008. About 45 seconds on VS2013. Both are autogenerated and essentially just a raw list of files built by the build system. I don't mind it very much, but the VS2013 is still doing who-knows-what background processing about two minutes later pegging two of my CPUs. That's on an i7 2720 (6MB cpu cache) with all the important stuff on SSD.

Even typing on the modern versions of Visual Studio feels slow. Considering the work required to display a screen full of text it should display faster than I can think about it. In the text-based world anything less than instant is slow, we render a few hundred thousand textured polygons faster than they can handle fixed-width text.

I've always thought it was sad that as hardware gets faster and faster, response times seem to get slower and slower. A typical example was when I learned Office 2013 introduced their animated letter display as you type to mask the internal delay. They enabled the smoothly-animated cursor and slowly rendered characters to mask the slow response seen by fast typists.

As for VS2013, the ALL UPPERCASE MENUS BY DEFAULT, the ugly gray-on-black fairly low contrast settings, and the "everything is ugly monochrome blocks like Metro" really turn me off. The constant alteration of features (often VS features are supported in every other release for some reason) is really annoying. VS2013 is not friendly at HTML editing; why did they remove the wonderful CSS Style dialog box that let you build and preview styles on the fly?! If you're editing HTML go back to VS2005 since it was the best of the lot over the past decade. Several of the command line tools are gone. Those are just a few of the reasons I keep versions all the way back to VS2005 on my machine.

Getting back to the original subject of the post... while I can understand the constant introduction of new features requires more resources, the transition of VS2008 to VS2010 took an unacceptable performance penalty, and MS has been going the wrong way ever since, where not even a high-end system can keep up with all the bad development going in to the system. Lately I've been doing a lot of development in other IDEs which are faster and target remote processes. When I use them I miss some of Visual Studio's features, but then when I open up VS2013 I immediately see the penalty it costs. Visual Studio requiring almost 300MB just to sit there with an empty project seems similarly obese, the last few rounds of the IDE are fat, slow, and bloated, in addition to being superficially ugly.

user logic: w/ a super machine a simple application will run lightning fast

dev logic: w/ a super machine, I dont need to give a shit to develop a simple application

over time, apps keep theyr performance, what changes is time to develop or top complexity..

~crude analysis of evolution of software by Icebone1000

¦D

user logic: w/ a super machine a simple application will run lightning fast
dev logic: w/ a super machine, I dont need to give a shit to develop a simple application

That is frequently the case, but for some programs it really ought not be the case.

An IDE, a tool for programmers by programmers, is something I'd expect to see some rock solid engineering. As it is, it reminds me of novices requiring 2GB to load a 1MB dataset.

Oh look, Intellisense performance improvements for VS2013: http://blogs.msdn.com/b/vcblog/archive/2014/09/03/vs-2013-update-4-ctp-1-is-live.aspx

Oh look, Intellisense performance improvements for VS2013: http://blogs.msdn.com/b/vcblog/archive/2014/09/03/vs-2013-update-4-ctp-1-is-live.aspx

Amazing!

Opening Unreal will no longer take about six minutes on that stupid blocking message. It will now block for slightly more than three minutes.

The occasional (at least hourly) "Please wait while we churn your disk for no discernible reason" will be reduced from three minutes to two minutes.

Let's see, each downtime results in about 10 minutes spent online, multiplied by at least 8 times every day, multiplied by all developers who use it, multiplied by their hourly salary, ... How many millions has this "feature" cost?

In the mean time I can just open the files in Notepad++ and start work immediately.