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

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register or Login
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

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. 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. 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.

Last edited by dude_1967; June 16th, 2010 at 03:58 AM.
Reason: spelling... typos

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

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.

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

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.

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

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.

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

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.

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

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?

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.

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

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.

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

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?

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

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.)

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

vs2010 ide was rewritten to managed code

Specifically the IDE was written in WPF.

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.

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

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.

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

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?

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?

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

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)?