Profiling Mysteries

DZone 's Guide to

Profiling Mysteries

Consider this strange case of a method that consumed CPU but was inlined away by the compiler. How does a profiler reveal the issue? How to figure out the real resource hog?

· Performance Zone ·
Free Resource

In our profiling, we run into an expensive mystery call to string.Join. Nothing in our code called it, and it is expensive.


Looking at the code didn’t get us anywhere, so I profiled things again, this time using the debug configuration. The nice thing about the debug configuration is that it doesn’t inline methods (among other things), so what gets executed is much closer to the actual code.

Here are the results:


And now it is clear what is going on.

Here is the offending line:

var tryMatch = _trie.TryMatch(method, context.Request.Path);

With context.Request.Path being a PathString, and TryMatch accepting a string, we are silently calling the implicit string operator, which just calls PathString.ToString(), which just calls ToUriComponent(), which looks like:

public string ToUriComponent()
    if (HasValue)
        if (RequiresEscaping(_value))
            // TODO: Measure the cost of this escaping and consider optimizing.
            return String.Join("/", _value.Split('/').Select(EscapeDataString));
        return _value;
    return String.Empty;

Looking into the current code, it has already been optimized by removing the Linq call and its associated costs, but that is still expensive call to make.

The fix was to get the string directly:

var tryMatch = _trie.TryMatch(method, context.Request.Path.Value);

And here is a 10% reduction in costs.

.net, profiling

Published at DZone with permission of Oren Eini , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}