devPartner C# project performance analysis

[James dean]

I am using devpartner performance analysis at the moment. I am trying to
locate the bad performance areas in my application. The session file
that is created has many headings. I want to know exactly how best to
read this data. There are headings and i want to know if i am reading
these results correctly. My understanding is as follows:
Top 20 methods-These are the 20 methods that take up the most time.
Real:The average execution time of the method. This is only the time
spent per call?....
Called:number of times the method was called.
If i multiply the called header by the real header then i get the total
time that this method used up in the running of the application.

I am finding it very hard to read the results as my program is slow but
all methods seem to be fast in execution so i guess the problem is in
how many times these methods are used. Could someone tell me a good way
to measure results to locate the slow areas. My project is a drawing
application by the way.......

 

[Bruce Wood]

I thought that the values shown are not the average execution time of
the method but the total time, expressed as percentages?

The results can also be difficult to read because the code is logically
"inside" multiple methods at once: if A calls B which calls C which
calls D, they are all counting "time" at the same moment, not just D.
So, you can end up with four methods each using up 60% of your run
time. Usually the ones higher up the call stack (A, B, and C) don't
matter as much. Or, sometimes, the problem is not that D is too slow
but that it's being called too often by C. The profiler can't tell you
which is the case; only you can figure that out.

 

[James dean]

Well those are "% in method" and "% with children".This tells you how
much time is spent in the method. "Real" is average execution time
including child methods. So is the only way to find out where my slow
methods are is by debugging?....

 

[Bruce Wood]

No, I use "% in method" and "% in children" to find the bottlenecks.
After all, if my program spends only 1% of its time in a method, I
don't care how slow it is. If my program spends 50% of its time in a
method, I'm going to see if I can make that method faster, because I
get a big payback for that.

I find that debugging doesn't help... it's looking at the code that
finds the problems. The profiler just tells me which methods merit my
attention and which ones don't matter.

As I said, the only tricky part is that sometimes it's the lowest child
method itself, and other times that child method is as efficient as it
can possibly be, and the problem is that one of the other methods is
calling it too often. However, at least the profiler cuts down the
number of places I have to look for efficiency gains.

The other thing that the profiler does is teaches me which Framework
methods are resource-intensive. For example, it will tell you that
opening an OdbcConnection costs big time. This may lead you to
rearrange your code--change your design--in order to minimize the
number of Open calls you make on an ODBC connection.

In the end, a profiler can't tell you where your "bottlenecks" are. It
can tell you is where it's worth looking for efficiencies, and where
it's not worth looking, and it can tell you what base operations are
"expensive" and which ones are "cheap".