Great language support, but are you addressing the performance issues?

Hello,

I have three or four questions below which require a bit of background information: which follows.

I am a long time user of Microsoft Developer Studio. In my development teams, we have consistently used this product line for a long time --- since Visual C++ 1.2 way back sometime around 1994.

We have seen versions of Visual Studio come and go over the years and, in general, we are very pleased with this product line. In fact, we like it so much that we even use Visual Studio 2008 for the cross development of embedded microcontroller applications --- surmounting significant extra work in the build environment just so we can take advantage of your wonderful editors, code completion (sometimes with plug ins like Visual Assist) and project management. What really makes the difference for us is a clean editor and IDE environment and very high quality language standards adherence.

However, with this newest version of Visual Studio 2010, the performance of the IDE is, well, simply put --- poor to say the least or better said, atrocious. :thumbd: The reactions of mouse scrolls, clicks, double clicks, file open, close operations, etc. are all slow, slow enough to really be noticed. Especially poor was the mouse scroll which requires a workaround on many XP machines --- the user actually needs to deactivate the default support for hardware acceleration in the graphic environment in order to avoid terrible window scroll performance. I would hardly call this a driver problem, rather a design weakness, a reliance on non-given user performance parameters. Many long time users of the Visual Studio product line all come to me and express the same concerns. They report that the IDE is slow --- slow in all aspects. It entirely lacks the snappiness that a tool of this quality requires. I also experience the GUI environment as poor.

It is so bad --- the poor quality of the IDE --- that it actually lends the impression that the overall quality of Visual Studio 2010 is poor. But nothing could be farther from the truth. Visual Studio 2010 (under the hood and beyond the poor IDE) is simply great. :thumb: The language standards adherence --- even supporting large portions of C++0x --- is spectacular. The new .NET implementation sets a milestone for development flexibility and ease.

We would like to know:

Are you aware of the uproar in the user community regarding these poor IDE performance issues?

Do you share the opinions of many others regarding poor IDE performance of Visual Studio 2010?

And if so, are you addressing the poor IDE performance issues? When will the user community see significant improvement in this area?

Sincerely, Chris.

I would like to add my support for the observations above. We migrated to VS2010 but within a week were forced to revert to using VS2008 due to the number and severity of bugs and performance issues.

The worst problem is that we have to recompile the entire application whenever we make a change to one of the resource header files. This is an absolute productivity killer. We submitted this as a bug ( https://connect.microsoft.com/Visual...t-source-files ) and were told that, despite the severity of the issue, it would never be fixed in VS2010. This is ridiculous. We were going to stick with 2010 in the hope of the problem being fixed in a patch but being told that the issue wasn't sufficiently serious was a major blow. I can't imagine what other problems there must be if this issue is regarded as being too trivial.

There are, of course, all sorts of other performance issues with Intellisense etc. that we hoped to see fixed but our confidence in Visual Studio is at rock bottom and sinking...

God knows, VS2008 has enough performance issues of its own but it is still far better than 2010. I'm sure all the shiny new stuff is great but it's no use if the editor is unusable. Why not try getting the basics right (like making the resource ID editor dialog resizable so you can actually see the IDs - very, very simple).

It's a shame that all the great new stuff is ruined by the lack of attention to detail and the arrogant no-can-do attitude. I suspect if there was a suitable alternative development environment then you would be motivated to fix these issues. Then again, if there was an alternative I'm sure we wouldn't be using Visual Studio at all.

I agree with the others. The IDE performance is abysmal. VS2008 pops up nearly instantly when clicked, but VS2010 takes a good 10-15 seconds for just the splash screen and 30 seconds or more before I get a usable IDE. I've nearly abandoned using the IDE and continue to use VS2008 for development and only load up VS2010 for the "code analysis" feature.

Hi Guys,

Are all of you using the RTM version released in April? There were major improvements made in performance from Beta2 to RTM. Are all of your issues related to C++? Are all of you using XP? Post your OS/Hardware specs and I will let the teams know.

I use Visual Basic and have only noticed a small slowdown in initial project load times on Windows 7.

-B

Thanks for your reply.

My team here are all using the RTM version on either XP or Windows 7. We develop large solutions in C++, MFC. I have Windows XP SP3, Quad Core 2.66Ghz, 4GB. We all seem to get performance issues but each developer reports different problems!

The resource header recompile bug is not related to OS version.

I get long, unexplained pauses when using VS2010. When Intellisense is enabled there are also big delays while the database is apparently being updated. I've turned off the error highlighting feature as that caused even greater performance problems.

From my own experiences, where I usually have issues is switching between form design and the code windows. Swapping between the tow causes the window to blank out, pause, then repaint itself. If I was editing the designer files directly, I could understand that, but if I switch over to the form view, select a text box, because I need the name, then switch back to my code.... I didn't change anything, and yet it seems to want to rebuild everything again. It's like the background compiler is being overly aggressive. And same thing when I switch back to the form view again... it does it all over again. Why?

As for specs - VS2010 Ultimate RTM.... computer is running Win7 64-bit, on an Acer PDC09. 2g RAM, Intel processor - can't remember if it's dual processor or dual core or neither.

Side question - is there a way to get intellisense to go back to the "starts with" filtering it used to do? I use intellisense to go object exploring. I used to be able to type ".t" and it would jumpt straight to the properties/methods that started with "t" ... now not only do I get those, but ANYTHING containing the letter "t" in it... It would be nice if it was something I could turn on/off in the options area somewhere.

-tg

I'm running the latest build, and on my Core-Duo laptop, performance is about the same as VS2008. It only has 4 gb of ram, and it's getting close.

The PowerTools added yesterday did wonders for the ADD REF.

In my VHD version, with 4 cores, it FLIES!

Quote:

---

Originally Posted by bethmassi

Hi Guys,

Are all of you using the RTM version released in April? There were major improvements made in performance from Beta2 to RTM. Are all of your issues related to C++? Are all of you using XP? Post your OS/Hardware specs and I will let the teams know.

I use Visual Basic and have only noticed a small slowdown in initial project load times on Windows 7.

-B

---

Yes, we are all using the MSDN premium version from Post 01-May-2010. VS2010 is slow on all systems that I have used. In my home office, I am running Intel Core2 Quad Q9400, 2.66 GHz, 4GB memory, Windows 7 Ultimate x64 --- which really should be enough machine and software muscle to manipulate text-based editing.

As far as I recall, the betas were even worse, catastrophically bad. I did not even take them seriously after the first try.

Let me try to be more precise with these observations. VS2010 seems to have the most problems with performance during transitions. Scroll and redraw is problematic. Starting VS2010 is very slow. Starting a compile session is slow, as is the transition to the link and code generation steps. Opening and closing windows is slow as is code navigation. And the worst performance deadlock of all comes when starting an external application within the build shell of an NMAKE makefile-based project.

In contrast, when running it is fast. For example, the performance of the C++ compiler is, in fact, very good --- that is as long as it is up and running and doing nothing other than sequentially compiling files in a project. The C++ compiler, when started and running, does fly. But starting the C++ compile stage or switchover to link and/or code generation stages crawls slowly on its hands and feet.

So if I were to do a very distant diagnosis of your performance bottlenecks, I would suggest that you look around the seams of the interfaces. How are the individual components put together and why is VS2010 taking so long to transition from one state to the next? You need to find out which major components play a role in such IDE state changes. You need to find out where they were programmed. Did you rely heavily on programming off-shore according to an interface specification? If so, then maybe performance was not even considered by some development partners.

You really can not talk this problem away and in my opinion you should not try to do so. Your shop is an absolute leader in producing state-of-the-art development tools. And whether you like it or not, VS2010 is very sub-optimal because its excellent language features are obscured by poor IDE performance. Oh well, maybe you can improve this product by improving the component integrations and tracing performance bottlenecks. I certainly hope so because we rely on the performance of this product.

Sincerely, Chris

Quote:

---

Originally Posted by AdrianAtSerif

I get long, unexplained pauses when using VS2010.

---

in fact long, unexplained and random pauses are also in older versions (i call them 'wait for signal from universe')
for me it's often related to putting a new breakpoint (what could take minutes without serious disk, network or cpu access?) or debugging generally
vs2010 ide was rewritten to managed code - are there any (unofficial) parameters we could play with? (f.e. something like often but shorter garbage collections?)
are there any performance statistics depending on hw or os? could investment to more than 4G memory and 64b os bring significant change?

Quote:

---

Originally Posted by real name

vs2010 ide was rewritten to managed code

---

Really. That explains a lot.

Anyway, I had also noticed very slow responsiveness, but until I saw this thread I had thought it was just my machine. (This Dell's hard drive is notoriously slow, but it's snappy once things are actually in memory.)

Quote:

---

Originally Posted by TechGnome

I used to be able to type ".t" and it would jumpt straight to the properties/methods that started with "t" ... now not only do I get those, but ANYTHING containing the letter "t" in it...

---

A small, but very annoying change indeed. :mad:
Either it's a mistake or someone wo doesn't use VS on a day to day basis for serious work thought it "sounds like a good idea".

Quote:

---

vs2010 ide was rewritten to managed code

---

Specifically the IDE was written in WPF.

Quote:

---

Either it's a mistake or someone wo doesn't use VS on a day to day basis for serious work thought it "sounds like a good idea".

---

I think it was based on feedback... I suspect from shops that have no naming standards so they would have trouble finding that list box of customers... so you could type Form1.Cus .... and get your lstCustomers, CustomerListBox, listOfCustomers.... you get the idea... It would also be nice if my intellisense was more consistent on when it filters by type.... I've done control.Color = and I get a nice list of the enumerated colors.... but what I want to assign it to is my color typed object I dimmed on the previous line. But if I try to set Control.Enabled = .... I get everything under the sun...

As a note... I'm not really expecting this to be changed... just voicing an opinion here.

-tg

A change on 2005 -> 2008 that caught me out was 2008 NOT saving all changed files before executing an external tool.
I lost the changes on several files when applying a source code formatter before I realised what had happened. Grr!

Microsoft please note: When you change the action or effect of a tool please please please give the user the default option to keep things the way they were. They may actually have preferred it that way.

Quote:

---

Originally Posted by TechGnome

From my own experiences, where I usually have issues is switching between form design and the code windows. Swapping between the tow causes the window to blank out, pause, then repaint itself. If I was editing the designer files directly, I could understand that, but if I switch over to the form view, select a text box, because I need the name, then switch back to my code.... I didn't change anything, and yet it seems to want to rebuild everything again. It's like the background compiler is being overly aggressive. And same thing when I switch back to the form view again... it does it all over again. Why?

As for specs - VS2010 Ultimate RTM.... computer is running Win7 64-bit, on an Acer PDC09. 2g RAM, Intel processor - can't remember if it's dual processor or dual core or neither.

Side question - is there a way to get intellisense to go back to the "starts with" filtering it used to do? I use intellisense to go object exploring. I used to be able to type ".t" and it would jumpt straight to the properties/methods that started with "t" ... now not only do I get those, but ANYTHING containing the letter "t" in it... It would be nice if it was something I could turn on/off in the options area somewhere.

-tg

---

Hi TechGnome,

Thanks for your comments. What kind of application are you using, when you experience slow perf switching between code and designer? WPF? Windows Forms?

Thanks!
Lisa Feigenbaum
Community Program Manager
Visual Studio

Quote:

---

Originally Posted by real name

in fact long, unexplained and random pauses are also in older versions (i call them 'wait for signal from universe')
for me it's often related to putting a new breakpoint (what could take minutes without serious disk, network or cpu access?) or debugging generally
vs2010 ide was rewritten to managed code - are there any (unofficial) parameters we could play with? (f.e. something like often but shorter garbage collections?)
are there any performance statistics depending on hw or os? could investment to more than 4G memory and 64b os bring significant change?

---

Hi "real name",

When you say that you often get random pauses (especially when setting a new breakpoint), is this during debugging or at design time? Also what language are you debugging/editing, what type of application is it (e.g. console application, WPF application, Windows Form, ASP.NET, etc.), and if the issue is while you are debugging, is .NET source stepping enabled, and do you have anything in your symbol path (Tools -> Options -> Debugging -> Symbols)?

Thank you,
Andrew Hall
Program Manager
Visual Studio Debugger

Quote:

---

Originally Posted by anhall1

Hi "real name",

---

it's during (mixed) debugging, mostly cpp; c# for wpf only (see next)
large mfc app, newly with some wpf dialog parts
i do not name long nearly-deadlocks(?) often, they're random (in that time the rest of computer lives own life without problem)
from history i'm used to this tricks: symbol path is usually empty (completely empty = no disabled items), not keeping unnecessary dll debug info (keeping list as small as possible), having minimum of breakpoints (and no disabled only), often closing not necessary source files opened, all intellisenses&co disabled, no pluggins like visual assist

Hi All,

Given that this slow chat has ended, can you please contact us at devperf (at) microsoft (dot) com to discuss these performance issues? We'd love to follow up with you and help diagnose the problem.

Thanks!
Lisa Feigenbaum
Program Manager
Visual Studio