VS2013 IDE/intellisense + VAX + performance (a kind of a rant-question-thing-thing)

Max Optional · 2014-09-05T14:58:52

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.

GDNet Lounge Community

Started by irreversible August 22, 2014 06:24 AM

9 comments, last by Bacterius 10 years ago

Bacterius

13,181

September 05, 2014 02:58 PM

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.

Think positive! Just imagine how many million man hours will be saved by these performance improvements!! This wouldn't have been possible if the software had been properly written to begin with!