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 https://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 https://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

  • Anonymous
    October 28, 2009
    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.

  • Anonymous
    October 28, 2009
    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.

  • Anonymous
    October 28, 2009
    The comment has been removed

  • Anonymous
    October 28, 2009
    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.

  • Anonymous
    October 28, 2009
    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.

  • Anonymous
    October 28, 2009
    Typing XAML still feels sluggish, and I don't have the code split view on.

  • Anonymous
    October 28, 2009
    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.

  • Anonymous
    October 28, 2009
    The comment has been removed

  • Anonymous
    October 28, 2009
    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

  • Anonymous
    October 28, 2009
    @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.

  • Anonymous
    October 28, 2009
    Hi! I'm very happy with VS2010 Beta 2 performance compared to Beta 1 or VS2008.

  • Anonymous
    October 28, 2009
    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.

  • Anonymous
    October 29, 2009
    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.

  • Anonymous
    October 29, 2009
    The comment has been removed

  • Anonymous
    October 29, 2009
    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.

  • Anonymous
    October 29, 2009
    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

  • Anonymous
    October 29, 2009
    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

  • Anonymous
    October 29, 2009
    I've seen some other reports of slowness in the XAML parser as well.  Maybe I can get some extra attention on that...

  • Anonymous
    October 29, 2009
    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!

  • Anonymous
    October 29, 2009
    >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!

  • Anonymous
    October 29, 2009
    The comment has been removed

  • Anonymous
    October 30, 2009
    ZhanboS, I will send you an email detailing the problem.

  • Anonymous
    October 30, 2009
    @ 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

  • Anonymous
    October 30, 2009
    Thanks, Raman. I'll put together some repro steps for the Intellisense problem and send them to you a little later on.

  • Anonymous
    October 31, 2009
    The comment has been removed

  • Anonymous
    November 01, 2009
    @ 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.

  • Anonymous
    November 02, 2009
    Josh, We are aware of and investigating the issue regarding stepping and having the memory and registers window show changes with color.  Thanks!

  • Anonymous
    November 02, 2009
    @ 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.

  • Anonymous
    November 03, 2009
    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?

  • Anonymous
    November 06, 2009
    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.

  • Anonymous
    November 07, 2009
    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.

  • Anonymous
    November 10, 2009
    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

  • Anonymous
    November 10, 2009
    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

  • Anonymous
    November 11, 2009
    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.

  • Anonymous
    November 14, 2009
    @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

  • Anonymous
    November 15, 2009
    The comment has been removed

  • Anonymous
    November 23, 2009
    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.  

  • Anonymous
    November 23, 2009
    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