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.