July, 2008

  • My Code Does What?!

    Excluding Small Functions From Instrumentation

    • 0 Comments

    In Visual Studio 2008, we added a feature to exclude small functions from instrumentation.  A small function is a function that has very few instructions and makes no function calls (i.e. it’s a leaf).  The idea behind this feature is that small functions are unlikely to be significant in the overall profile of your application, so we can skip collecting data for them altogether to avoid the overhead of otherwise doing so.  This feature is meant to exclude property getters and setters, but it will also exclude very simple functions that are typically inlined anyway.

    The first benefit of this feature is reduced instrumentation probe execution overhead.  Typically, small property getters and setters incur the time cost of executing two probes: the enter and exit probes.  The execution time of these probes dwarfs the execution time of the getter or setter itself.  To top it off, this cost is paid on every single property access which can be frequent.  By not instrumenting these property getters and setters, we can reduce execution overhead.

    The second benefit is reduced profile data file (.vsp) size.  Fewer probes means less data collected.  If you’ve done instrumentation profiling before, you probably know that the data files can grow quickly.  Keeping file sizes smaller facilitates sharing and faster analysis.

    The third benefit is reduced noise in your profile.  Since we don’t collect any data for these insignificant functions, they won’t even show up in your reports.  This is similar to, but independent of, the new noise reduction feature in VS2008.

    With this feature enabled, it’s important to note that the time spent executing a small function does not just disappear.  Instead, the time gets attributed to the callers of the function excluded.  For example, if Foo calls SmallFunc, the exclusive time of SmallFunc when Foo called it is added to Foo’s exclusive time.  It’s as if the function was inlined at all of its call sites.

    Small function exclusion is enabled by default which can, on occasion, cause issues.  Really simple projects such as a default C# console application or a default WCF service, are essentially infrastructure code in addition to (nearly) empty functions.  Because of this, profiling one of these default project types immediately after creation will typically yield “Error VSP1734 : File contains no data: ...” since nothing gets instrumented (they’re all small functions, after all).

    You can disable small function exclusion by opening an instrumentation target’s properties, selecting the Instrumentation section, and unchecking “Exclude small functions from instrumentation”.  Each instrumentation target has its own value for this property.

    target-props exclude-small-funcs

    If you’re instrumenting your binaries on the command-line using vsinstr.exe, you can specify /excludesmallfuncs to exclude small functions from instrumentation.  The default command-line behavior is to instrument everything.

  • My Code Does What?!

    Sample Profiling And Stdin

    • 0 Comments

    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.

Page 1 of 1 (2 items)
Search
Recent Posts