I suggest you ...

Improve the performance of Visual Studio

Visual Studio seems to be getting slower. Please focus on improving the performance and limiting the enormous load on the HDD

5,178 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Koen WillemseKoen Willemse shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →
    Niclas CarlstedtNiclas Carlstedt shared a merged idea: Visual studio performance (Bad UX)  ·   · 
    DejanDejan shared a merged idea: Visual studio designer still slow?!  ·   · 
    SomeGuySomeGuy shared a merged idea: Remove the stalls.  ·   · 
    Yan XijianYan Xijian shared a merged idea: I hope that Visual Studio 2010 has a much faster launch speed~~  ·   · 
    completed  ·  Visual Studio teamAdminVisual Studio team (Product Team, Microsoft) responded  · 

    Thank you to all who provided ideas and votes on this topic. We used that data to help prioritize the improvements in Visual Studio 2012 and have been continuing this work with the VS 2013 release.

    As Visual Studio 2013 Preview has now shipped, we’d like to close this item to give your votes back to use on specific topics. Our Visual Studio performance team will continue working to improve performance at an ongoing basis. However, we are closing down this general idea, so that you can use your votes on more specific performance topics, and help us focus our team’s investments. When you have performance related suggestions, please create or vote on specific Perf ideas here: http://visualstudio.uservoice.com/forums/121579-visual-studio/category/52115-performance

    Please use Visual Studio 2013 Preview (http://go.microsoft.com/fwlink/?LinkId=306566) and continue your feedback and votes– we highly value your feedback.

    Visual Studio Team

    92 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • acac commented  ·   ·  Flag as inappropriate

        The startup issue with sleeping hdds spinning up afaik is due to Customer Experience Improvement. Turn CEI off in options and it should go away.

      • David RathboneDavid Rathbone commented  ·   ·  Flag as inappropriate

        Simple VS2010 is a text editor!,
        And C,C#,C++,VB.net, ASP.net use a compiler
        all thats left to do is have a visual syntax editor for .net or raw language.

        Even better would be if Microsft could make its"Window's" Form components have a working form designer!

        All the rest is just very slow over kill.
        e.g. Kiss

      • KevinKevin commented  ·   ·  Flag as inappropriate

        try upgrading to an SSD, (recommend Intel 510, can be used for either a desktop or laptop, and can run in both 3Gb or 6GB if your system supports it) boot times are much faster, overall system response and of course VS activities such as loading the app, compiling code etc are noticeably improved...

      • Knowing me, knowing you, a-haKnowing me, knowing you, a-ha commented  ·   ·  Flag as inappropriate

        @David funny that whenever you try to explain something to Java guys (will it be Java from Sun or Java from Microsoft) they never seem to/want to understand.
        As I've said, fiesta driver will never understand what Ferrari driver is talking about when he talks about speed/performance.
        As for alexei guy, leave him alone, clearly he has little idea what is he talking about and you would waste more of your time than it's worth it.
        C++ Rules and Rocks!
        Forever!

      • Alexei KAlexei K commented  ·   ·  Flag as inappropriate

        @David you are being rediculous comparing Notepad with VS. I am comparing the very same UI component of VS with VS and the same version of VS. So no, your arguments hold no meaning and therefore no value.

      • David ColeDavid Cole commented  ·   ·  Flag as inappropriate

        @Alexei:

        > The fact that the same environment works splendidly for some technologies and horribly for others, pretty much rules out the presentation layer and puts the blame solely on the underlying machinery (aforementioned compiler, reference resolution, and other maps of things to things).

        No.

        This is like saying that since Notepad can edit the readme.htm file provided with Visual Studio 2010 just fine, it can be used just fine with any text file, even if it is a gigabyte in size. We all know this is not the case, Notepad chokes on large text files.

        There are many differences between C++ projects and C# projects, which make C++ projects 'heavier' for the IDE than C# projects: I'd argue that C++ projects are typically significantly larger (many reasons), that parsing headers is generally much more complex and time-consuming than parsing assemblies, that the use of preprocessor makes things even worse for C++, that templates are generally more demanding with respect to coloring, Intellisense, debugging and everything else than generics, etc.

        Because of this, a WPF-based IDE (or text editor) might be good enough for an average project in C#, but very bad for an average project in C++.

      • Alexei KAlexei K commented  ·   ·  Flag as inappropriate

        Compilers aren't written in managed code, neither are the debugger, intellisense or other tools. It seems the problem is precisely with the unmanaged devs pretending they are actually Ferrari owners. It may have been a Ferrari when they bought it, but you've got to know how to drive it. If you left the transmission a few miles back and the wheels exploded before that, it's not really a Ferrari anymore, is it?

        Wonder how far we can take this analogy?

        Point is, it's the unmanaged side of VS code-base that's broken, leave managed alone and fix what's broken. As David pointed out, resources aren't infinite and are far better spent fixing things and adding features, than doing re-writes.

      • Knowing me, knowing you, a-haKnowing me, knowing you, a-ha commented  ·   ·  Flag as inappropriate

        @Alexei, the fact is that you and all of .NET crowd drive a fiesta, but most of this crowd pretend that they drive ferrari or don't want to see that what they drive is actually just a fiesta.
        And still can't/don't want to understand that the managed code is the problem.

      • Alexei KAlexei K commented  ·   ·  Flag as inappropriate

        OK, with that disparity settled, there is only one more thing I'd just like to point out. The fact that the same environment works splendidly for some technologies and horribly for others, pretty much rules out the presentation layer and puts the blame solely on the underlying machinery (aforementioned compiler, reference resolution, and other maps of things to things). Both managed and unmanaged environments show the same things, it's the machinery that gets the data to show that's different.

        So I do stand by my original call to leave WPF alone, it's the gleaming coat of red paint on my Ferrari, I'd rather no one scratched it :)

      • Knowing me, knowing you, a-haKnowing me, knowing you, a-ha commented  ·   ·  Flag as inappropriate

        @Alexei, that explains everything. As I've said in my earlier post, someone who drives ford fiesta will never have any idea what guy who drives ferrari is talking about when he talks about speed/ performance.

      • David ColeDavid Cole commented  ·   ·  Flag as inappropriate

        Well, Alexei, this explains it all. I should have noted you are talking about managed code. I am talking solely about C++. For a C++ developer, the performance of VS2010 is simply horrible, this is why you see numerous cries to improve it, on this site and elsewhere. For a managed code developer, things might be different. Sorry for the confusion.

      • Alexei KAlexei K commented  ·   ·  Flag as inappropriate

        @Knowing my first post here clearly says managed :) no need to ask me anything.

      • Knowing me, knowing you, a-haKnowing me, knowing you, a-ha commented  ·   ·  Flag as inappropriate

        @David and Anna I think that it is important and even I would say vital to ask Alexei one simple question:
        Do you develop (on every day basis) in managed or unmanaged code?

      • David ColeDavid Cole commented  ·   ·  Flag as inappropriate

        @Alexei:

        I guess we will have to agree to disagree, but:

        > The old editors would slow down horribly if you did frequent edits at the bottom of a very large files (many thousands of lines, easy to get with partially generated wrappers). The new one is blazing fast, no matter where in the file I edit.

        I don't see this at all. I mean *at all*, that's so far from my experience -- and I do write C++ code in VS day in and day out -- I wonder if we are talking about the same product. Yes, the performance of VS2008 was not always stellar, but VS2008 can *easily* handle the same files and projects VS2010 can't. For my team, on our projects (maybe that's where our environments differ, maybe we have more LOCs or something), in comparison between VS2008 and VS2010, it is VS2008 which is blazing fast no matter where in the file bla bla whatever. And it is VS2010 which is slower to start with and which would slow down considerably even more with each passing hour.

        Your other point baffles me as well. What, all those people who were busy redoing the IDE in WPF could do nothing else useful? Surely, whoever was rewriting parts of the IDE could instead apply their efforts towards extending the IDE in other ways, whoever was profiling and tuning the new IDE could instead have been profiling and tuning the old IDE, whoever was finding and fixing bugs in the new code could instead have been finding and fixing bugs in the old IDE, and so on. I am not sure what you are arguing here...

      • Alexei KAlexei K commented  ·   ·  Flag as inappropriate

        @David The move to WPF may not have had a huge effect on editor as such, but the move to 2010 certainly did. The old editors would slow down horribly if you did frequent edits at the bottom of a very large files (many thousands of lines, easy to get with partially generated wrappers). The new one is blazing fast, no matter where in the file I edit. Eric Lippert alludes to some of the changes in his post here (http://blogs.msdn.com/b/ericlippert/archive/2011/07/19/strings-immutability-and-persistence.aspx) and you could probably push him to do a follow up blog post to compare/contrast with old editor. He likes going into details :)

        And we didn't get WPF instead of C++0x or any other features, I highly doubt that the guys doing presentation layer are the same ones who are handling languages an other features like debugger. So I disagree with all of your disagreements :)

      • David ColeDavid Cole commented  ·   ·  Flag as inappropriate

        @Alexei: My 2 cents:

        > I am still certain that WPF is a red herring of performance issues. There was massive rework of back-end for 2010, and the fact that the obviously visible change to the user is WPF, makes people correlated WPF with the cause of slowness. Just because they happened at the same time, doesn't mean the two have any relationship.

        It is, of course, true that the move to WPF and .NET involved rewriting a lot of code and thus it is possible that the real reason for the performance degradation is not WPF or .NET per se, but rather issues in the design of the new code. That said, this is not the first time I see a project move from unmanaged code to managed, and I can't help but notice that such moves usually result in performance issues (the reverse is true as well). Granted, WPF is likely not the whole problem, but it definitely seems to me that it is part of the problem.

        > But let's say there is a relationship, and we do pay in performance, look at what we've gained. Text rendering quality in WPF got a huge boost from VS adopting it.

        Well, WPF got a boost, but what VS got in return? Does the source code look better now? No. Does it render faster, maybe? Heck, no, this is the entire topic of this and other threads, that VS2010 is *much slower* than previous versions. The truth is, there were plenty of issues with the new WPF-based text editor in the beta. The text was blurry, the performance was bad, etc. Well, the team fixed one of these issues, the text is no longer blurry. But, what, are we supposed to celebrate because of this? Even though most of the remaining issues have not been fixed??! I seriously don't get this.

        > The adoption of MS tech by major MS product is nothing but a good thing, they (and us) just need to keep pushing for improvements.

        I disagree. Instead of moving to WPF, the development team might have added some more C++0x features, might have worked on the performance of parallel builds, might have added more C++-centric features to the IDE, etc. Heck, they might have fixed some of the bugs reported on Connect, many of them have been lying there for years and the standard reply is "we don't have infinite resources, this is a bug, but it doesn't meet our bug bar, so we aren't fixing it". The adoption of MS tech (WPF) by major MS product (VS2010) is thus NOT nothing but a good thing, this adoption has deprived us of many useful features and bug fixes.

        > Another re-write (as a lot of people demand) so soon will just cause more issue (more fresh bugs). They will be somewhere else, but we as uses will be no better off. The motivations should be to fix the things that are broken, not re-write the same thing over and over (introducing v1 bugs again and again). Old editor and the rest of the UI, was ancient, it couldn't go on, a re-write was needed. Re-writing it again is Sisyphus' labour.

        I disagree again. Nobody is arguing for multiple rewrites. What I want to see is a single rewrite in unmanaged code, and no rewrites after that. Yes, rewrites are bad, but bad rewrites such as this one are doubly so. Do you want VS to remain managed forever? I sure don't. I don't buy this ".NET is fine, it's other things that slow everything down" line. I heard it too many times and I am yet to see a .NET application that would deal with non-trivial amounts of data with the same speed as a C++ application. Unmanaged code has more legs than managed code. Let's move back to unmanaged code and be done with it, at least for C++ development.

      • Anna MetcalfeAnna Metcalfe commented  ·   ·  Flag as inappropriate

        @Alexei Apologies for the long post - I've a lot to say on this subject, and to a great extent I've said most of it before elseware. Anyways...

        > @Anna, on your last point (VS extension dev) you have an huge ally :) VS development team. So even if they couldn't get everything right in the first re-write, they are sure to improve, because it affects them directly, arguably more so than other devs working on plugins/extensions.

        One would hope so; in practice I can tell you from experience that extension developers generally have a rough time whenever a major change happens in the Visual Studio codebase - as a browse through Carlos Quintero's blog (http://msmvps.com/blogs/carlosq/) during the period of any of the VS betas should illustrate.

        Suffice it to say that the last two VS versions with major changes (VS2005 and VS2010) were still both pretty badly broken at beta 2; at least with VS2010 MS listened to reason and issued a release candidate which meant the RTM was better than it otherwise would have been. VS2005 never had that, and still has noticable breaks (e.g. the Add-In Manager) to this day. By contrast VS2003 and VS2008 were a breeze, which leads me to observe that VS releases follow a two step release pattern - major reelase with breaking changes (VS5, VS2002, VS2005, VS2010), then consolidation release (VS6, VS2003, VS2008).

        On the VS2010 front believe me we've had to invest far more time than is reasonable for a new version working around bugs in VS2010 that just shouldn't be there so late in the day - so much so that once again I honestly believe they tried to change far too much in this release (our experience was far worse than VS2005, and that's saying something).

        > Still has VS UI ever locked up on you in 2010? Are any of the problems rooted in the fact that UI can't render? Not for me, at least. VS 2005/2008 used to lock up all the time on me (2008 less so), I couldn't keep VS open for more than a day, I would shutdown in the evening and re-open in the morning. The only slowdowns in 2010 for me come from underlying things like parsing projects, compiling, building maps of the large code-base (identifier refences, occurances, etc.), code analysis and re-factoring tools (esp. 3rd party). You can see much more serious issues in Avery Lee's post, none of which seem to be UI issues.

        I've not found a version of VS yet that hasn't died or froze on me at some time; same with Eclipse. The worst one for me at least) seems to be VS2005 - something very weird seems to be going in with the internal COM interfaces in that version.

        > I am still certain that WPF is a red herring of performance issues. There was massive rework of back-end for 2010, and the fact that the obviously visible change to the user is WPF, makes people correlated WPF with the cause of slowness. Just because they happened at the same time, doesn't mean the two have any relationship.

        It may turn out to be - but given the timing of the change between CTP and Beta 1, I'd say the editor work very likely has a (possibly big) part to play.

        Regardless, it needs to be sorted. Get the memory footprint and responsiveness of VS2010 to the same level as VS2008 and I'll be a lot happier regardless of what technology they use to do so - WPF, native or whatever. I'm sure others will be too.

        > But let's say there is a relationship, and we do pay in performance, look at what we've gained. Text rendering quality in WPF got a huge boost from VS adopting it. The adoption of MS tech by major MS product is nothing but a good thing, they (and us) just need to keep pushing for improvements. Another re-write (as a lot of people demand) so soon will just cause more issue (more fresh bugs). They will be somewhere else, but we as uses will be no better off. The motivations should be to fix the things that are broken, not re-write the same thing over and over (introducing v1 bugs again and again). Old editor and the rest of the UI, was ancient, it couldn't go on, a re-write was needed. Re-writing it again is Sisyphus' labour.

        The fact that WPF has evolved as a result is almost entirely irrelevant to me - I'm far more interested in C++ 11!

        I'd argue that big rewrites are what got us where we are now (the C++/CLI Intellisense fiasco demonstrated the same symptoms - committing to too large a change in a single release), and that a far more incremental rapid-release approach would work better for VS anyway. If the changes in VS were more controlled and less "Hey guys this is big and new and shiny! Isn't it cool?" I'd be happy to migrate to a new VS SP every 3-6 months, and a new major version every two years.

        As it is, we regularly (every second release) skip a major version (we skipped VS2005, too - prior to VS2008 we were on VS2003).

      • Alexei KAlexei K commented  ·   ·  Flag as inappropriate

        @Anna, on your last point (VS extension dev) you have an huge ally :) VS development team. So even if they couldn't get everything right in the first re-write, they are sure to improve, because it affects them directly, arguably more so than other devs working on plugins/extensions.

        Still has VS UI ever locked up on you in 2010? Are any of the problems rooted in the fact that UI can't render? Not for me, at least. VS 2005/2008 used to lock up all the time on me (2008 less so), I couldn't keep VS open for more than a day, I would shutdown in the evening and re-open in the morning. The only slowdowns in 2010 for me come from underlying things like parsing projects, compiling, building maps of the large code-base (identifier refences, occurances, etc.), code analysis and re-factoring tools (esp. 3rd party). You can see much more serious issues in Avery Lee's post, none of which seem to be UI issues.

        I am still certain that WPF is a red herring of performance issues. There was massive rework of back-end for 2010, and the fact that the obviously visible change to the user is WPF, makes people correlated WPF with the cause of slowness. Just because they happened at the same time, doesn't mean the two have any relationship.

        But let's say there is a relationship, and we do pay in performance, look at what we've gained. Text rendering quality in WPF got a huge boost from VS adopting it. The adoption of MS tech by major MS product is nothing but a good thing, they (and us) just need to keep pushing for improvements. Another re-write (as a lot of people demand) so soon will just cause more issue (more fresh bugs). They will be somewhere else, but we as uses will be no better off. The motivations should be to fix the things that are broken, not re-write the same thing over and over (introducing v1 bugs again and again). Old editor and the rest of the UI, was ancient, it couldn't go on, a re-write was needed. Re-writing it again is Sisyphus' labour.

      • Anna MetcalfeAnna Metcalfe commented  ·   ·  Flag as inappropriate

        @Alexi I think of it as more of an educated guess than an assumption - bear in mind what I mentioned about the CTPs.

        Having seen the far higher number of functionality breaks than usual in the command/editor interfaces of VS2010 during the beta cycle it seems reasonable to assume that the VS team had far bigger problems than perf at the time. Now that VS2010 is at least stable that now needs sorting as a priority.

        Spinning up disks may well be a problem too, but I reckon the issue goes significantly deeper than that.

        BTW I work on VS extensions, so I start new instances many times a day - often under debug or in VMs. For this, the perf of VS2010 sucks bigtime compared to previous versions.

      Feedback and Knowledge Base