dotnet performance: Hi, I've just started teaching myself how to use the CLR Profiler. I recently profiled my global.asax's "application_error" code that emails unhandled exception info to me(i profiled the execution of one request that posted a form which threw an exception). I'm not sure what to make of the results since I have no baseline to compare the result to. Please let me know what you think if you're familiar with intepreting Clr Profiler Results.

The profiler's allocation graph for this code tells me that the exception cost 139KB. Is this 'expensive' code(from what I hear exceptions are expensive to begin with).. for exception handling code is this horrible, average, high performance? The code grabs the expetions type name, call stack, message, the page's form, user info from the browser capabilities class and some server variables. I build the body of the email message using a stringbuilder which I set by counting the amount of characters in the exception's message, stack and typename.
ie:
Dim ex As Exception = Server.GetLastError().GetBaseException(
Dim exLen As int3
With e
exLen += .stacktrace.Lengt
exLen += .TargetSite.Name.Lengt
exLen += .message.Lengt
End Wit
Dim sb As New StringBuilder(exLen

Here's the break down of the data behind the allocation graph
System.Web.HttpApplication::RaiseOnError void (): 139 kB (100.00%
ASP.Global_asax::Application_Error void (Object ): 139 kB (100.00%
System.Web.HttpValueCollection::ToString String (): 55 kB (39.78%
System.Text.StringBuilder::Append System.Text.StringBuilder (String): 52 kB (37.41%
System.Text.StringBuilder::set_Capacity void (int32): 15 kB (10.44%
System.Web.HttpBrowserCapabilities::get_ClrVersion void (): 5.7 kB (4.10%
System.Text.RegularExpressions.Regex::Match static System.Text.RegularExpressions.Match (String String): 4.1 kB (2.92%
System.Web.Mail.SmtpMail::Send static void (System.Web.Mail.MailMessage): 2.8 kB (2.00%
System.Text.StringBuilder::.ctor void (int32): 1.7 kB (1.24%
System.Exception::get_Source String (): 898 bytes (0.63%
System.Web.Mail.MailMessage::.ctor void (): 492 bytes (0.35%
System.String : 416 bytes (0.29%
System.Web.HttpServerUtility::UrlDecode String (String): 274 bytes (0.19%
System.Web.HttpServerUtility::UrlEncode String (String): 270 bytes (0.19%
System.Text.StringBuilder::Append System.Text.StringBuilder (Object): 208 bytes (0.15%
System.RuntimeType::get_FullName String (): 76 bytes (0.05%
System.Reflection.RuntimeMethodInfo::get_Name String (): 76 bytes (0.05%
System.Web.Mail.MailMessage : 64 bytes (0.04%
System.Text.RegularExpressions.GroupCollection::get_Item System.Text.RegularExpressions.Group (int32): 52 bytes (0.04%
System.Text.StringBuilder : 40 bytes (0.03%
System.Text.RegularExpressions.Capture::get_Value String (): 24 bytes (0.02%
System.Security.FrameSecurityDescriptor : 24 bytes (0.02%
System.Int32::ToString String (): 20 bytes (0.01%
System.Text.StringBuilder::Append System.Text.StringBuilder (int32): 20 bytes (0.01%
System.Text.StringBuilder::Append System.Text.StringBuilder (float64): 20 bytes (0.01%
System.Text.RegularExpressions.Match::get_Groups System.Text.RegularExpressions.GroupCollection (): 20 bytes (0.01%
System.Object::GetType System.Type (): 16 bytes (0.01%

Hi Chris,

yes, I would think that 139 kB for a request throwing an
exception is expensive.

Whether you need to worry about it depends on whether the
exception happens frequently. If most requests throw
exceptions, then this might be a performance problem. If
exceptions are rare, then there might be more important
things to worry about.

What it really boils down to is the average amount of
memory allocated per typical request. This number
determines to a large extent the throughput you can
achieve.

Of course, the bottleneck can be elsewhere - say in
accessing a database server or whatever.

To get a handle on whether memory allocation and garbage
collection is even a problem in your app, bring up
perfmon and watch the .NET CLR Memory/Allocated Bytes/sec
and ~/% Time in GC perf counters (with your app under
heavy load, obviously). If the numbers you see there are
high (say over 20 MB/sec or over 10% of the time in gc),
there may be value investigating and optimizing the
allocation behavior of your app.

If you need to analyze, running a few typical requests
under CLRProfiler and analyzing their allocation behavior
is a good start. For best performance, you want the
amount of memory allocated per request to be relatively
low (say under a 100 kB).

If that's the case, but the "% Time in GC" perf counter
is still high, you may have a problem with too may
objects surviving garbage collections. This is often
caused by overuse of finalizers. The doc that comes with
CLRProfiler has more explanation on this.

Thanks
Peter
[quoted text, click to view]
Profiler. I recently profiled my
global.asax's "application_error" code that emails
unhandled exception info to me(i profiled the execution
of one request that posted a form which threw an
exception). I'm not sure what to make of the results
since I have no baseline to compare the result to.
Please let me know what you think if you're familiar with
intepreting Clr Profiler Results.
[quoted text, click to view]
that the exception cost 139KB. Is this 'expensive' code
(from what I hear exceptions are expensive to begin
with).. for exception handling code is this horrible,
average, high performance? The code grabs the expetions
type name, call stack, message, the page's form, user
info from the browser capabilities class and some server
variables. I build the body of the email message using a
stringbuilder which I set by counting the amount of
characters in the exception's message, stack and
typename.
[quoted text, click to view]
System.Text.StringBuilder (String): 52 kB
(37.41%)
[quoted text, click to view]
System.Text.RegularExpressions.Match (String String):
4.1 kB (2.92%)
[quoted text, click to view]
System.Text.RegularExpressions.GroupCollection::get_Item
System.Text.RegularExpressions.Group (int32): 52
bytes (0.04%)
[quoted text, click to view]
System.Text.RegularExpressions.GroupCollection ():
20 bytes (0.01%)
[quoted text, click to view]