August, 2008

  • My Code Does What?!

    VS2008 SP1 Website Profiling Bug And Workaround

    • 2 Comments

    out-of-range 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.

    build-menu

    configuration-manager

  • My Code Does What?!

    Visual Studio 2008 Service Pack 1 Released To The World!

    • 0 Comments

    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.

  • My Code Does What?!

    Walkthrough: Profiling With Automated Tests

    • 0 Comments

    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:

    test-results

    test-results-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.

    performance-wizard

    performance-explorer 

    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.

    summary

    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.

Page 1 of 1 (3 items)
Search