A couple of weeks ago I blogged about the performance improvements in Visual Studio 2008.
In response to that, several of you asked me for more information on how these types of enhancements had been incorporated into Visual C++.
Though the performance improvements blog highlighted work the Visual C++ team had done around file-level parallel builds and incremental builds for mixed native-managed projects, there are other things in for VC++ in VS 2008 that I thought would be worth mentioning. So, here we go:
· Editor responsiveness – Updating IntelliSense, displaying the QuickInfo tooltip and processing AutoComplete requests won’t degrade editor experience.
· Goto Definition improvements – Significant reduction in the time required to “Goto Definition”. One customer reported that a 2 minute delay dropped to 10-20 seconds.
· Load solution performance – Load time of large Visual C++ solutions is much better. Some customers are reporting speed ups of 25%-70%.
· File lookup in projects – Provides improvements to several scenarios such as adding files to projects, changing configurations, etc.
· Changing configuration options – Modifying options, such as adding an include directory or changing the active configuration, are much faster for large solutions.
· Reduced CPU consumption – We now process low-priority background items (such as IntelliSense population) using 20% less CPU time.
I do hope that all this work will provide a much enhanced IDE experience for C++ developers. The Visual C++ team is already hard at work on the next major version of Visual C++ and is hoping to address even more performance and scalability issues in the future. Also, for those of you working on Visual C++ 2005, the team will be releasing a patch that applies the fixes described above to that version as well.
Namaste!
PingBack from http://www.artofbam.com/wordpress/?p=7017
Soma just blogged about some of the performance improvements we're making in Visual C++ 2008 . We'll
Soma just blogged about some of the performance improvements we're making in Visual C++ 2008 . We'll
Somasegar's WebLog has a entry on VC++ Performance Improvements in VS 2008 . A couple of days ago he
Somasegar, jefe en Microsoft Corp. de muchos de los avances de la plataforma .NET, ha realizado unos
[原文地址]: VC++ Performance Improvements in VS 2008 [原文发表时间]: Wednesday, October 10, 2007 5:59 PM 几个星期前
In general, it all sounds good.
However, VC++ 2005 is seriously lacking in standard compliance. Can I expect any serious improvements? Specifically:
1) Two-phase name lookup
2) Exception specifications
3))Export *
* While many may not like it, it is part of the standard.
I'm using VS2008 beta2. I found that if I double click on a lNK2001 or C1083 error message in the output window, VS hangs for a while before it finds the file.
Steps to reproduce:
It is time for another weekly roundup of news that focuses on .NET, agile and general development related
Fei,
> if I double click on a lNK2001 or C1083 error
> message in the output window, VS hangs for
> a while before it finds the file.
Yes, Linker errors which are not linked to a specific file in the project could exhibit this behavior while the IDE tries to find the file (that does not exist) in your project. I can imagine that this could take a long time if you have large solutions. It's not something that we fixed in VS2008, unfortunately. Thanks for bringing it to our attention.
I'm not sure why you should be getting this for C1083 if it's related to an existing source file, though. Perhaps this was about a compiler-generated file? If so, we would definitely be interested in the "steps to reproduce" that you missed above.
Thanks,
Tarek Madkour
Lead Program Manager
Microsoft Visual C++
Any information on speed improvements in generated code would be helpful.
Microsoft has too many disasters on his hands to be worried about fixing exception handling and export, both of which are broken in the standard itself. If these features were simple and reliable to implement, were in widespread use or even remotely useful then it would be worthwhile. However, none are the case.
>>One customer reported that a 2 minute delay dropped to 10-20 seconds.
Here is what I'm wondering. Let's say there are a million symbols in the database. Let's assume the database is in a binary tree, and every node requires one disk access. This means there will be 20 reads, at 10 milliseconds each. Worst case scenario: 200 milliseconds. Hard to do worse than that, theoretically at least. Now, how can you guys possibly spend 10-20 seconds looking ANYTHING up? Please tell us. I really, honestly, truly don't understand how a lookup could take this long.
I'm very happy with your promise that the performance improvements will be rolled into 2005. It makes it easier to justify buying 2008 knowing that I'm buying it for features not for bug fixes. Thanks.