VS2010 Beta2 performance and other issues


Just a few words of encouragement today:  I can’t emphasize enough how valueable your feedback is to us at this point; no matter how hard we try we simply cannot duplicate the diversity that is the real world.  We need to know what’s really working out there — what works for us isn’t enough.  Whether it’s performance, stability, or any other issue, your feedback will help us to “get it right” for the release.


I’ve seen some super-positive comments about product performance and I’ve seen some negative ones.  Your comments will help us to figure out which areas we’ve missed, what combinations aren’t working, what hardware are we using poorly, or any other goofy thing we might have done.


You can use http://connect.microsoft.com/ or you can provide comments here.  We’re even watching twitter and the blog-o-sphere generally but those are less reliable.


Brian Harry is also reaching out http://blogs.msdn.com/bharry/ and I know all the other executive bloggers have their ears on — and they’ll get help.  Connect bugs are the best of all but don’t be shy, we’ll take the feedback however we can get it.


Thank you!

Comments (38)

  1. Rico,

    Perf has been great for me. Stability has been bad. In particular, editing XAML with the editor opened caused VS to crash 8 times in 1 hour of usage.

    I don’t report issues like this; I figure you guys already know about this, given VS submits a crash report, and given others have certainly run into it.

  2. Stephan says:

    Stepping over machine instructions  in the disassembly view (managed code) is extremely slow and seems to get even worse over time. There’s also a bug which for the first few times forces one to hit F10 twice for every debugger step because every other F10 highlights the "Command Window" icon in the toolbar instead of triggering a step. As it is the debugger is pretty much unusable in the disassembly view.

  3. 1- One very annoying thing in all previous VS and that is still present in 2010 is that all projects are expanded by default in the solution pane. There are various addins that have a "Collapse all projects" option .. that should be a sign that this behavior is not desired.

    2- While testing the conversion of our internal framework VS2008 solution, the target framework of all projects was set to 2.0, while in the original solution, some of them are targeting 3.5.

    3- For the "Add a reference dialog", would it be possible to add a new tab that shows core .NET assemblies only ? That .NET tab and the project one will be the most used and the async one will really be a last resort. About the current .NET tab, its async behavior makes it really hard to select an assembly while it is loading as the listbox keeps refreshing itself… Also, it would be nice to have a filter/search box and make the dialog much bigger by default.

  4. Oh, and up to now, performance has been fine for me, except the memory footprint, something you already mentioned in your last video on channel9 🙂

    I am impressed by the WPF interface responsiveness. It has made me wonder if I should not I should start  recommending WPF for LOB and other large data entry applications.

  5. Tom says:

    Performance of beta 2 compared with beta 1 is greatly improved overall – great job!

    But, I don’t like how the new Add References dialog works. Selecting the Projects tab by default is a good idea, but the problem is when you select the .NET tab, it is confusing.

    It looks like you are populating the list after the tab is clicked. If the user don’t realize this at first, he/she starts looking for a particular item, but then might not see it in the list.

    I would suggest that you somehow indicate to the user that the list is incomplete.

  6. Harold says:

    Typing XAML still feels sluggish, and I don’t have the code split view on.

  7. tom says:

    It takes much longer time to switch between build types, e.g. debug->release, in the property sheets than it used to be for C++ projects.

  8. GrayShade says:

    As others have said, after a few hours I’m getting big slowdowns in typing speed; also, the "black text which gets coloured later" effect is a bit distracting.

    On the bright side, the font selection part of the Options dialog is finally fast.

    But I’m rather worried about .NET 4 performance; it seems to be slower in many cases. MeasureIt confirms this.

  9. Kamran Shahid says:

    Lots of improvement from beta1.

    One thing from features perspective is the lacking of Xml/XSD tools. some features like XML enterprise should be supported.

    Also like if there is some feature to generate C# classes as we can generate from XMLspy enterprise edition.

    I am talking about http://forums.asp.net/p/1454624/3328326.aspx post

  10. Andrei Rinea says:

    @Kamran Shahid : As kavita_khandhadia told you on the ASP.NET forums there is XSD.exe available since like… 2003.

    What you might ask for here is a visual tool that builds on this existing tool.

  11. Hi!

    I’m very happy with VS2010 Beta 2 performance compared to Beta 1 or VS2008.

  12. tobi says:

    Text has become much clearer but is still a little inferior to VS08. I am using Vista 64, Font Envy Code R size 8 in both products.

  13. Jim Griesmer (MSFT) says:

    To Stephan in particular, the F10 bug mentioned about the disassembly window is a known Beta2 bug and will most certainly be addressed before we ship. In the meantime you may be able to get by by utilizing the stepping Debug toolbar buttons rather than F10.  

    We are also aware of the refreshing issues of this window that affect perf and it is something we’re addressing.

  14. Played with beta 2 last night. Had a few issues running on 7 64bit on a core 2 machine.

    1. Simple WPF application froze VS for 10-15 while looking at a control’s properties minutes.

    2. One of the times I ran the app the debugger behaved like something is running, but no client view opened.

    3. The help on a browser sucks.

    4. Did Help on GUID has and the code samples were truncated. Trying to send feedback put garbage characters in the e-mail so I let it go.

    5. Disappointed that there is no 64 bit version, but that’s another story.

    All in all I like where this is going to and I’ll keep horsing around with it, but more work to be done for sure. Keep up the good work.

  15. ricom says:

    Thank you for the comments so far! In addition to reading these myself I’m also asking selected groups to monitor for feedback.  Many eyes are on this posting as well as Brian Harry’s and several others.

    Connect bugs remain the best way to get specific issues resolved but we also value the kind of "gut feel" stuff that comes across easily here.

  16. Stefan Olson says:

    Rico,

    Beta 2 certainly is a huge improvement over beta 1.

    However I still feel that typing into the C# editor on anew install is slower than Visual Studio 2008.

    The xaml editor is very much slower, as an example if I want to move 10 characters to the left and I hold down my arrow key, it keeps going for a long period of time after I’ve let it go.  Unfortunately I can’t turn ReSharper off at the moment to check if that’s making it worse.

    …Stefan

  17. Stefan Olson says:

    Rico,

    I’ve turned ReSharper off now and the xaml editor is still ridiculously slow moving the caret around via the keyboard.

    My gut feeling on speed is that it is still substantially slower than 2008.  From the time that I press F5 to my application appears is a lot worse than 2008 (on a small project).

    …Stefan

  18. ricom says:

    I’ve seen some other reports of slowness in the XAML parser as well.  Maybe I can get some extra attention on that…

  19. Zhanbo Sun says:

    I am from Cider team that owns WPF/Silverlight designer.

    To Judah Himango: Thanks for your comment. You mentioned that "In particular, editing XAML with the editor opened caused VS to crash 8 times in 1 hour of usage."

    Can you provide a bit more detail by answering the following questions?

    (1) Do you see VS crash at such frequency for one particular project, or for any project you have tried?

    (2) Usually VS crashes after you made some editing in XAML pane. If possible at all, can you describe a few scenarios in more detail (with sample XAML and action that result in VS crash) so that I can repro them. We assure you that they will get fixed.

    (3) If you edit in Full XAML view (i.e. you maximize XAML pane), do you experience less VS crash?

    Please feel free to contact me directly for Cider related issues. My email is: ZhanboS AT Microsoft DOT con. If you prefer, you can also post your answer here.

    Thanks in advance!

  20. Zhanbo Sun says:

    >Harold said on October 28, 2009 9:34 PM:

    >Typing XAML still feels sluggish, and I don’t have the code split view on.

    Hi, Harold, thanks for your feedback regarding XAML editing experience.

    If I understand it correctly, you are editing XAML in full XAML view.

    What if you try editing in split view (i.e. you see both designer and XAML editor)? Will the performance be essentially the same, or worse?

    In comparison with Visual Studio 2008 SP1, do you feel the performance essentially the same, or worse?

    Can you also answer the following 5 questions?

    (1) Do you feel the slowness all the time or from time to time?

    (2) If you simply move text cursor around with arrow keys (so there is no typing or actual editing), do you feel the same way?

    (3) For the default MainWindow.xaml (which has just 8 lines), do you feel the performance is sluggish when you edit it?

    (4) Can we ask you try the C# or VB code editor in the same project? Are their performance much better? How about your experience with editing aspx file?

    (5) What is the hardware configuration of your system? Do you connect to it via remote desktop/terminal service by any chance?

    Please feel free to contact me directly for Cider related issues. My email is: ZhanboS AT Microsoft DOT con. If you prefer, you can also post your answer here.

    Thanks in advance!

  21. For me, help has been pretty shaky in beta 2. I started out trying the local server, and it’s way too slow on my machine (64-bit Windows 7, 3GHz dual-core Pentium D, 8GB). I switched to Internet retrieval, which is much faster (20mb connection), but the help results are strange. If I start a new Win32 application project, click on the ShowWindow API function, and press F1, I’m sent to the help page for COleControlSite::ShowWindow (yesterday it was a completely different MFC class). If I move down a line to UpdateWindow and press F1 I get the expected help page.

    Other than that…

    I really like the changes to the environment. Intellisense still seems a little shaky in C++ with regard to namespaces, but overall the experience has been positive.

  22. ZhanboS, I will send you an email detailing the problem.

  23. Raman Sharma [msft] says:

    @ Paul M. Parks

    Hi Paul,

    Thanks for your feedback.  

    Re: F1 Help

    We are aware of some issues with respect to the accuracy of F1 Help results and are actively working to improve the experience.  The issues are not in the Visual Studio product per se but in the way your F1 query is matched to the appropriate help page on MSDN.  We are making improvements to that mechanism and some of those will be ready only after Beta2 i.e. the next publicly available release.

    Re: Intellisense

    I am not quite sure what issues you have faced with Intellisense and namespaces.  Would you be able to provide more information and clear repro steps?

    Please feel free to contact me directly at:

    rasharm at microsoft dot com

    And we can discuss this and other issues you might have faced.

    You could also create a Connect bug through:

    https://connect.microsoft.com/VisualStudio/feedback/CreateFeedback.aspx

    We look forward to hearing from you.

    Thanks

    Raman Sharma

    Visual C++ Team

  24. Thanks, Raman. I’ll put together some repro steps for the Intellisense problem and send them to you a little later on.

  25. Josh Pschorr says:

    In addition to the F10 issue and dissassembly window refresh issues mentioned above in the comments, I’m also not seeing memory and register modifications colored as the ‘register data changed’ and ‘memory changed’ font settings would dictate.

    Modifications are shown appropriately in the Watch/Locals/Autos windows, but not the Memory or Register windows.

    Note: I’m stepping through the dissasembly for (unmanaged) c++.

  26. JulianR says:

    @ GrayShade:

    I’ve just tested this and my testing seems to confirm what you’re saying. Executing a simple benchmark was measurably slower in VS2010 than in VS2008. Now, I say in VS and not in .NET 4 because performance is identical when simply running the .exe outside of VS. Running the benchmark from 2010 also often gives wildly erratic results. My guess is that after launching the program, VS still does something CPU intensive, messing with small micro benchmarks that finish in under a second.

  27. Jim Griesmer (MSFT) says:

    Josh,

    We are aware of and investigating the issue regarding stepping and having the memory and registers window show changes with color.  Thanks!

  28. Li Shao says:

    @ Sebastien Lorion

    You had this comment:

    2- While testing the conversion of our internal framework VS2008 solution, the target framework of all projects was set to 2.0, while in the original solution, some of them are targeting 3.5.

    I suspect that the projects you have are C# or VB, please confirm if that is the case.

  29. timb says:

    I’d like to +1 Paul’s comments about local help.  I’m finding it ridiculously slow to start up – 30 seconds on one machine (Intel Quad Core 4G XP64/SP2, lightly loaded, other than VS itself) – and VS blocks for most of the wait.    Back in the early 90s you could get help in half a second on a 20Mhz 386.  How did we get from there to here?

  30. J. Passing says:

    I have been doing C# Add-In development using Vs2010, which of course requires debugging devenv using devenv. The performance of this is so utterly abysmal that it is hardly usable: Not only does symbol loading during startup take around 2 minutes (When will the VS debugger finally learn to do lazy symbol loading?), each single step takes around 2-5 seconds! In fact, debugging using VS2010 is even slower than kernel debugging over a serial cable — this is completely beyond my comprehension.

    On the same hardware (dual-core, 2GB of RAM), VS2005 and 2008 run perfect and with good performance, but VS2010… it is a disaster, really. I hope the situation improves until RTM.

  31. Stephan says:

    Am I the only one who finds the font rendering in the editor window of VS2010 still inferior to the one in VS2008? When comparing the rendering of Consolas text at font size 10 the rendering in VS2008 seems a bit less blurry. The difference is quite subtle now, but its definitely noticeable. Is this maybe an operating system issue, since no one else seems to be noticing this? I’m still using Win XP Pro 64-bit (with ClearType switched on, of course). I hope there will be still some fine-tuning of the WPF font rendering.

  32. Fabiano says:

    Judah already pointed this out, but opening a XAML file causes VS to crash most times.  Sure this is a beta product but Im surprised a bug this big made it out.  I am running it on Vista Home Premium 64bit

  33. Thad says:

    I agree with Judah and Fabiano. VS 2010 Beta 2 crashes and hangs quite frequently when working in WFP projects. Perf is OK for me. Feels a little slow at times but usable if stabiliyt wasn’t so bad. Win 7 7100

  34. Eric Fisk says:

    I am from the XAML designer team. Fabiano and Thad- thank you for raising the issue of designer stability. If you find a particular stability or performance issue that’s reproducible it would be great if you can create a connect bug for the issue. This method guarantees the issue gets dealt with: http://connect.microsoft.com/

    Beyond that, we are continually assessing automated crash reports, so please keep them coming our way by sending that information to Microsoft.

  35. @Li Shao

    Sorry for not replying sooner.

    Yes, all projects in our framework are in C# and most have been converted to VS2008 format from VS2005.

    If you want more information, you can reach me at sl AT thestrangefactory.com

  36. Li Shao says:

    @Sebastien Lorion

    Hi Sebastien,

    Thank you for replying. Someone from our team will be in contact with you regarding this issue.

    For the other two issues you raised:

    1- One very annoying thing in all previous VS and that is still present in 2010 is that all projects are expanded by default in the solution pane. There are various addins that have a "Collapse all projects" option .. that should be a sign that this behavior is not desired.

    3- For the "Add a reference dialog", would it be possible to add a new tab that shows core .NET assemblies only ? That .NET tab and the project one will be the most used and the async one will really be a last resort. About the current .NET tab, its async behavior makes it really hard to select an assembly while it is loading as the listbox keeps refreshing itself… Also, it would be nice to have a filter/search box and make the dialog much bigger by default.

    We have opened bugs for them in our database and they will be considered for next release.

    Li Shao, MSFT

  37. Build times are horrendous for a VERY small WPF hobby project.  On a Core i7 920 (OC’d to 3.3ghz), 12gb RAM, 3x120gb OCZ Vertex SSD drives in RAID 0, Win7 x64, .NET 4.0 x86 target framework, single project in the solution… 33 seconds to build.  No static code analysis, addins, etc.

    Enabling the msbuild diagnostic logging shows the culprit is:

       31349 ms  CoreCompile                        2 calls

    A much larger project for work with 21 projects in the solution in VS2008 takes less than 10 seconds to build on the same machine.   Compiling this large solution (again wtih diagnostic msbuild) shows the build times are now 1 minute and 28 seconds.  

  38. To clarify – compiling the large solution in VS2010 beta 2 now yields 1:28 compile times versus the original sub-10 second builds in VS2008.

    Contact me at giorgio at giorgio galante dot com

    if you have additional questions