In the VS 2008, we have made some good strides in improving performance for some of the common scenarios that developers care about. We set explicit performance goals both for new product features and for improving the performance of existing features.
For example, with the new LINQ facility we set a goal that LINQ performance be significantly better than using a SqlDataAdaptor for the same query and competitive with using a SqlDataReader, the lightest weight interface available for retrieving data from SQL Server. In our testing, LINQ does in fact out-perform SqlDataAdaptor on almost every test case we tried, and in many of the exceptions, it is no more than 10% slower than using a SqlDataReader to accomplish the same task. Given the power of LINQ, we feel this is a very reasonable trade-off.
Some of the more prominent performance improvements in Visual Studio 2008 that we see include:
· Rebuilding a Visual Basic project and running a background compiler is 3x faster and uses 3x less memory. More about this topic here.
· Scrolling large C# files in the Editor is 100% faster, while typing in new text is 50% faster
· The response time of IntelliSense with large types in C# is up to 10 times faster
· Incremental build time runs up to 90% faster on C++/CLI project solutions. More about this topic here.
· Office Word and Excel files are processed 20x faster on the server
· TFS Version Control command processing was re-written to support unlimited sized operations on key commands without being memory bound on the server. In our measurements, key Commands also run 10% - 60% faster, with the larger improvements associated with bigger projects. More about the work to improve TFS scalability here and here.
We also focused on performance improvements that exploit multi-core hardware. As I blogged about earlier, we added multi-threaded support to MSBuild. In addition, using the /MP switch, you can significantly improve your C++ project build time – internally we’ve seen improvements of up to 30% when building the C++ Frontend compiler on dual-core hardware. Significant performance improvements were also made in the .NET Framework 3.5 runtime to streamline the CLR thread pool to help multithreaded applications of all kinds. These architectural changes, when combined with socket API changes, improve asynchronous socket I/O throughput up to 70% when a 2nd processor core is available, for example. The full scope of this work is discussed in more detail here.
These are just some highlights. There are many other performance improvements. I am sure there are areas we can do better as well. Like anything else, this is a journey and not a destination.
Namaste!
PingBack from http://www.artofbam.com/wordpress/?p=3507
It is time for another weekly roundup of news that focuses on .NET, agile and general development related
Thanks for the post!
I am interested what other speed improvements you have done to VB, apart from that one for the project file?
Does the LINQ facility works the same(have the same speed improvement) if we use C# or VB?
Cheers!
Is it planned to have a Release Candidate before the final release of VS2008 and if so do you recommend people who are running live sites on Beta 2 to upgrade to RC or wait till RTM?
Soma just blogged about VS 2008 Performance Improvements . There is some good info in his post. One of
David Hayden has a post on his blog concerning this:
http://davidhayden.com/blog/dave/archive/2007/09/28/LINQToSQLVisualStudio2008PerformanceUpdate.aspx
I'd comment on his blog but he has them disabled for some reason.
Soma, will this issue be fixed by release?
David (if you read this) can you post the SQL queries generated by those DataLoadOptions in your example? In theory it should just be 1 query, using JOINS it should bring in all the data in 1 call from all 3 related tables. Yes there is duplicated data but that is better than "too many" SQL trips IMO.
Can you tell me if you've made improvements to the disaster that is the VC++8.0 SxS deployment system?
Travis,
We actually looked into various options for eager loading (DataLoadOptions) queries and did fair amount of reasearch. The conclusion was that "big join" type queries for more than two tables often are less performant than n queries as we do. In fact we used to big join in earlier previews and reverted back for correctness and performance.
Besides duplicate data, there are other issues there as well - consistency under normal isolation level (i.e. correctness) and the increase in the likelihood of deadlocks on a loaded server when more multi-table queries are issued. See http://blogs.msdn.com/ricom/archive/2007/08/31/database-performance-correctness-compostion-compromise-and-linq-too.aspx for more insights into some of these issues.
Bottom line, based on our investigation, what may be perceived as an improvement is not one in many common cases. That said, there are more optimal ways to do DataLoadOptions that we came up with. However, we did not have time to do work on that scale within V1 scheule constraints. We hope to explore that post-V1.
Dinesh Kulkarni
Sr. Program Manager - LINQ Project
Developer Division
Hi ajaxus,
Thank you for your inquiry. Yes, there are additional performance improvements included in Visual Basic 2008. Stepping, first-time intelliSense, errors in the task list, editor responsiveness, large solutions, and web apps are a few examples of areas where we have focused on improving performance. Cameron McColl, VB perf developer, has created a video on Channel9 where he talks about and demonstrates several of these scenarios:
http://channel9.msdn.com/ShowPost.aspx?PostID=328382#328382
As far as how LINQ runs in VB vs C#, there are some common parts... Both use the same APIs in .Net Fx 3.5, both utilize the same LINQ providers, and both are using the same underlying technology. However, there are some differences too, such as the different (but similar) expression trees that are produced using the VB and C# compilers. Both teams have taken performance into account in their designs, however. So this should not be a reason choose one language or the other. If you do happen to experience any problems with either, you can email VB Performance (vbperf@microsoft.com) or CSharp Performance (vcsperf@microsoft.com) and we will be happy to look into it.
Thanks,
Lisa Feigenbaum
VB IDE & Perf Program Manager
Hello Larry,
With regard to improvements to the VC++8.0 SxS deployment system, unfortunately there are no changes to the deployment scenario in VC9.0. On the other side, we realize that there is some pain there. We currently have plans to look into that (even if a redesign is needed) and hence would like to hear more about the issues you are facing and your suggestions for improvements. Please feel free to contact me directly at aymans at microsoft dot com
Ayman Shoukry
Lead Program Manager
Visual C++ Team
1. Pls include x64 compilers in C++ 2008 Express.
2. Pls include MFC and ATL in C++ 2008 Express.
3. Pls include Class View in VB 2008 Express.
[原文地址] VS 2008 Performance Improvements [原文发表时间] Thursday, September 27, 2007 4:52 PM 在 VS 2008 中 ，我们就开发人员所关心的一些常见的使用场景在性能上作了很大的改进