My Code Does What?!

Visual Studio 2010 Beta 2 Available Now!

2009-10-22T21:00:43Z

On Monday, we released Visual Studio 2010 and .NET Framework 4 Beta 2 to the web! In the new, simplified product lineup, you will find the profiler in the Premium and Ultimate editions.

We’ve made a lot of progress since Beta 1 with the profiler and with the product in general. We would love to get your feedback and impressions on it:

Post issues and questions in the Beta 2 support forums
Submit bugs or suggestions through Microsoft Connect
Tweet your experiences with the #vs2010 tag

Our Beta 1 feature blogging was put on hold in favor of fixing bugs, so as we inch closer to RTM, we will be posting in-depth information about the new goodness in the profiler as a part of Visual Studio 2010.

Until then, I leave you with a little more screenshot love :) (click to embiggen)

Fig 1. New summary page.

Fig 2. Function details view.

Fig 3. Thread contention view.

Fig 4. Tier interactions view.

Fig 5. Performance wizard.

Fig 6. We’re on the Debug menu! I <3 Alt+F2.

Visual Studio 2008 AJAX Profiling Extensions Power Tool

2009-04-30T05:56:38Z

Originating in Microsoft Research as Ajax View, the Visual Studio 2008 AJAX Profiling Extensions Power Tool was released today (download here). It’s a JavaScript performance profiler with a novel approach: it modifies the code sent by your server to include diagnostic code to trace and time function execution. The client browser then sends profiling data back to your server for aggregation and analysis as the JavaScript executes. Once you’ve collected your data, you can install the power tool extensions for VS2008 Team Developer or Team Suite to view and analyze the results using the Visual Studio Profiler’s UI.

The benefit of the server-side instrumentation approach is that it works with any client browser, letting you see how various browsers affect your performance. On the server, you must be running IIS7 with an integrated pipeline. Currently, running this power tool on production servers is not recommended.

Between this power tool, the built-in IE8 JavaScript profiler, and the integration with Visual Studio, we hope to shine much needed light on client-side browser performance.

Website Performance Talk at MIX09

2009-04-21T21:19:24Z

John Hrvatin, lead program manager on the IE team, recently gave a talk at MIX09 entitled “Building High Performance Web Applications and Sites” (see the presentation key below). John goes over a number of common performance pitfalls encountered when developing websites with CSS and JavaScript as well as some issues you might encounter at the HTTP level. Some of the presentation’s content can be found in Steve Souders’ High Performance Web Sites book, but John goes more in depth on JavaScript issues and where IE8 has addressed specific problems.

John also gives a demo of IE8’s new JavaScript profiler which gives you absolute timings and call counts for your JavaScript functions. This is a great first step, giving you the raw data you need in order to see where time is being spent in the browser. To jump right in with IE8’s JavaScript profiler, check out the “How Do I: JavaScript Profiler” video.

Integrated JavaScript profiling will also ship with Visual Studio 2010, though you’ll get a richer analysis and reporting experience with tools like hot path, call tree trimming and folding, .csv and .xml exporting, VS IDE integration, and the function details and caller/callee views. A future blog post will go more in depth on this.

Presentation Key

Time	Topic
00:00	Intro, motivation
05:53	CSS performance 05:53 – Minimize included styles 06:57 – Simplify selectors 09:14 – Don’t use expressions 10:09 – Minimize page re-layouts
13:14	Optimizing JavaScript symbol resolution 14:01 – Lookup chains 15:53 – Local variables 16:52 – Implicit lookups 18:10 – Multiple DOM lookups 18:51 – Function lookups
20:10	Demo - Internet Explorer 8 JavaScript Profiler
23:44	JavaScript coding inefficiencies 23:44 – Parsing JSON 26:36 – The switch statement 28:18 – Property access methods 29:23 – Minimize DOM interaction 34:23 – Use querySelectorAll for groups
37:06	HTTP performance 37:39 - HTTP compression 38:44 - Scaled images 39:45 - File linking 41:18 - Many images 42:49 - Repeat visits 44:06 - Script blocking 47:55 - Tools
49:07	Summary
50:30	Q & A

Patch Released To Fix Sampling On Intel Core i7 Processors

2009-02-25T09:32:02Z

A hotfix has been issued for those of you trying to do sample profiling on Intel’s Nehalem-based processors, the most recently released being the Intel Core i7 family. Previously, trying to do so would result in a blue screen of death (i.e. Windows crash, machine lockup and reboot). Not very useful. With this patch, sampling should work as usual.

If you’re running Visual Studio 2008 SP1…

If you’re running Visual Studio 2005 SP1…

See The Profiler At PDC2008

2008-10-27T10:39:35Z

Steve Carroll, development lead for the Visual Studio Profiler, will be at PDC2008 next week giving a presentation on the profiler:

What: TL24: Improving .NET Application Performance and Scalability
When: Wednesday, October 29th, 1:15pm - 2:30pm
Where: Room 153
Abstract: “Performance must be considered in each step of the development lifecycle. See how to integrate performance in design, development, testing, tuning, and production. Work with tools and technologies like: static analysis, managed memory profiling, data population, load testing, and performance reports. Learn best practices to avoid the performance pitfalls of poor CPU utilization, memory allocation bugs, and improper data sizing.”

If you’re going to be there, it’d be worth checking out some of the new features we’ve been working on as well as seeing how the profiler and load testing tools in Visual Studio Team System can help you improve your software.

Visual Studio Profiler: Found A Bug? Have A Suggestion?

2008-09-05T23:46:55Z

The profiler is not flawless. We work hard every day to improve it, however, and we’re always listening to and considering your feedback. The profiler exists to help you, so if you feel it has shortcomings or if it fails to fully address your scenario, please let us know. The more we hear from you, the more we know what’s important, what’s lacking, and what we should tweak. Your feedback informs our daily decisions and sets the tone for future development.

Luckily, using Microsoft Connect, you can easily file a bug or give us suggestions for improvement. After you’ve signed into Connect (Live ID required), you can go through the Visual Studio Feedback Center to submit a bug or a suggestion. The higher quality bug or suggestion you file, the more likely we’ll be able to help you. There’s a lot to be said about how to file an actionable bug, but please try to include the following:

If applicable, the smallest project possible with which you can reproduce the issue
A concise but complete set of steps to reproduce the issue
If you’re profiling from the command-line, include the commands verbatim
Is your OS 32- or 64-bit? Is your target application 32- or 64-bit?
What anti-virus/-spyware/-malware applications do you have installed?
If it’s an instrumentation issue, include the binary (.exe, .dll) that you’re trying to instrument along with the matching symbols (.pdb) for that binary
Include as much CPU information as possible including the number of sockets and cores as well as details for each CPU
Do you have any custom build steps, build scripts, pre-/post-build events, or custom output locations?
Do you have any special deployment for your binaries? GAC? NGEN?
What Visual Studio edition are you using? If any, what other Visual Studio editions do you have installed?
What language is your application written in? C#? C++? Managed C++? Any assembly?
Include any error strings, error codes, or screenshots of errors

Alternatively, if Connect feels too heavyweight or impersonal, you can contact us directly or post a question or suggestion in the profiler forums.

VS2008 SP1 Website Profiling Bug And Workaround

2008-08-23T01:38:38Z

Visual Studio 2008 Service Pack 1, while fixing many profiling bugs, has also unfortunately introduced an issue with website profiling. If you have a website project created with a pre-SP1 version of Visual Studio and then try to profile it using instrumentation with VS2008 SP1, you might run into a rather vague error: “Value does not fall within the expected range.”

Thankfully, there is a simple workaround: open the Configuration Manager from the Build menu, and for each of your website projects listed there, change its Platform to “Any CPU”. Be sure to make these changes for each configuration type defined for your solution (e.g. Debug, Release). You should now be able to successfully profile your website using instrumentation.

Visual Studio 2008 Service Pack 1 Released To The World!

2008-08-12T08:51:51Z

After months of development and some grueling bug fixes, we released the VS2008 SP1 patch to the web this morning. You can check out more details in the readme. For the profiler, we fixed a number of bugs including:

Adding support for instrumenting 64-bit managed C++ applications
Improved instrumentation experience with precompiled websites
Shipping the 64-bit performance SDK (VSPerf.h, VSPerf.lib)
Ability to load a previously saved filter on non-English VS installations
Numerous fixes around comparing profiling reports
Numerous fixes around function name (symbol) resolution
Numerous IDE fixes

The standalone profiler has also been updated to include the profiler’s SP1 fixes. If you do profiling on production machines or other environments where minimal footprint is a virtue, you’ll want to use this updated, full installer.

As always, if you have questions or feedback, feel free to contact us or post a message in our forums.

Walkthrough: Profiling With Automated Tests

2008-08-07T09:35:00Z

When doing performance investigations, we recommend having some well-defined scenario in mind in order to increase the reproducibility of your issue and increase the consistency of profiling data collected. This approach is similar in spirit to creating the smallest self-contained repro possible when debugging. When diagnosing any complex system, limiting the variables involved is a key step to discovering a solution.

Automated testing can often lead to naturally self-contained scenarios. Integration tests ensure the correctness of a subsystem as its separate components work together. If you test large portions of your application in this manner frequently enough, it is possible to catch performance issues and regressions before they become too serious. With the profiler and test integration added in VS2008, once you notice a regression, you can create a performance session directly from the slow test via its context menu:

This will lead you to the Performance Wizard where you must decide between instrumentation and sampling. Which method you should use depends upon the type of application you’re profiling and the kinds of questions you’re trying to answer. Once you’ve completed the wizard, you’ll get a shiny new performance session ready to be launched. You’ll see below that, in this case, our primary project and profiling target, Intergalactic.exe, is marked for instrumentation while the unit test is what we’ll be launching.

After launching the profiler, the test will execute as normal, exercising your code under the profiler. The benefit of this approach is that reproducibility is maximized since the scenario is defined in code. After the test completes, you’ll get a performance report to assist you with further investigations.

Performance sessions can be created from unit tests, web tests, database tests, and load tests containing web tests. Load test and web test profiling will only work if you’re running against a web site or web service hosted locally in IIS or Cassini. The reason for this limitation is that the profiler must run on the same physical machine as the target process in which you’re interested. If you must profile a web site or web service running remotely, try using the command-line tools included in the standalone profiler, referring to this blog article for guidance.

Sample Profiling And Stdin

2008-07-30T00:08:00Z

Some command-line applications can read from stdin for use as program input. The canonical example of this is sort.exe which sorts the list of strings given to it and prints it back out to the console:

C:\Temp> type letters.txt
m
z
a

C:\Temp> sort < letters.txt
a
m
z

Sample profiling an application that reads from stdin is a bit trickier than typical sample profiling. It is not easily possible from the VS IDE, so you have to drop down to the profiler’s command-line tools. The command-line tools support passing arguments to the target program via vsperfcmd /args, but a stdin file parameter is not considered to be a program argument. In other words, the following does not work as you might expect:

vsperfcmd /start:sample /output:profile.vsp /launch:sort.exe /args:”< letters.txt”

This will behave as if you launched sort.exe “< letters.txt”. Unfortunately, this is not the intent here. In order to get around this, we can use cmd.exe’s built-in start utility and its background feature. The start utility is the Swiss Army knife for launching programs. Its background feature lets you launch a command in the background without creating a new cmd window while still passing through any stdin parameters. Knowing this, and assuming we’re profiling a native application, we can create a simple batch file to get the job done:

start /b sort.exe < letters.txt
vsperfcmd /start:sample /attach:sort.exe /output:profile.vsp
vsperfcmd /shutdown

Because we are attaching after launching the application, we will probably miss a few samples at the beginning. Having these commands in a batch file, however, ensures that we miss as few samples as possible. For any real workload, losing a few samples should not be an issue.

Interestingly, instrumentation (trace) profiling does not suffer from this issue at all because of the way in which instrumented binaries are launched. To achieve the above with instrumentation, you can simply do the following:

vsinstr sort.exe
vsperfcmd /start:trace /output:profile.vsp
sort.exe < letters.txt
vsperfcmd /shutdown

If all else fails, or if your scenario is more complicated than above, you can always just modify your application to use a hardcoded input path.