0

I'm using Equatec profiler to diagnose a slow process of my application. I figured out which method is slow, but I want to know specifically which part of the method is slow. Aside from breaking up the method into multiple methods is there a way through the Eqatec Profiler API to mark specific sections of a method to be profiled separately from the entire method?

Eric Anastas
  • 21,675
  • 38
  • 142
  • 236

2 Answers2

1

Equatec is a good profiler, but in my experience here's what happens in a good-size .net app.

You may find a routine that's active a good percent of the time, like 20%, and you might even find a particular "hot" line inside it, but you can look at it and not really know what to do about it, because as far as you can tell, it's necessary.

At the same time, there could be something bigger than that lurking in the code that doesn't really show up very well in the profiler, because it's not confined to one routine.

If I can just give one example, I've seen an app that spends roughly 50% of it's startup time 20-30 levels deep in the call stack getting strings from resources just so it can display them to the user to let them know what's taking so long. If it found another way to do that it would start up twice as fast! The ANTS profiler (another good one) gave no clue as to what was happening.

How did I find it? The old-time method, same way it's done here, and is explained here.

The following graph shows, if you manually sample the stack N times, by pausing the program, and on two of those samples you see it doing something you could replace with something much faster, the amount of time you can expect to save, and the corresponding speedup ratio.

For example, the red curve (2/5) means if you take five stack samples, and you see what you could improve on two of them, you don't know precisely how much you will save. However, the most likely value is 2/5(40%, speedup 67%), the average is 3/7(43%, speedup 75%), and it would be somewhere in the range roughly between 10% (speedup 11%) and 70% (speedup 3.33x). That's in case you're thinking you can't trust small numbers of samples. Not a bad gamble. If you want more certainty, take more samples.

Beta distribution of cost for seeing something on S samples out of N total samples.

(Plot of Beta distribution X ~ Be( number of hits + 1, number of misses + 1 ) and Speedup = 1/(1-X).)

Community
  • 1
  • 1
Mike Dunlavey
  • 40,059
  • 14
  • 91
  • 135
  • Your "startup time 20-30 levels deep"-example would be detected by the EQATEC Profiler: it always shows you the culprit, ie the method taking most time in total, and is not tricked by the fact that the expensive method was called from many other methods. That's a pretty powerful feature, in my humble opinion. – Richard Flamsholt Mar 19 '12 at 00:16
  • @Richard: If you remember, I was not able to run EQATEC on it, but I was able to run ANTS. Maybe ANTS is only a shadow of EQATEC, I don't know, but it works on the same principle of measuring method percents. That's the problem. There are lots of methods, call tree or not, with high percents. You look at them and they all look perfectly good. It isn't until you put aside measurement and instead examine a number of deep samples in time and ask "*why* is this moment being spent?" that the problem appears. Measurements don't give reasons, and the problem doesn't appear without them. – Mike Dunlavey Mar 19 '12 at 02:14
  • I think ANTS is a fine profiler, but it can apparently get tricked by your example. Instead of thinking solely in call-trees and percentages the EQATEC profiler instead looks at the total for each and every method, so those taking up most time will "bubble up" to the top of the list of suspects. (BTW your problem back then was caused by signed assemblies - if you re-sign or skip these then it should work) – Richard Flamsholt Mar 19 '12 at 07:22
  • @Richard: Sorry I haven't had a chance to pursue that yet. It's lonely, but I'm suggesting an alternate paradigm: if one only looks for methods (or even lines of code) taking the most time, some things to fix to get speedup *will be totally missed*. I keep wondering if I'm wrong, *[but it's true.](http://sourceforge.net/projects/randompausedemo/files/)* By measuring time of routines, you will see some things and miss others. Then the ones that are missed are the ones that become dominant as others are removed. To find them one needs to examine moments in time, not measurements. Try it & see. – Mike Dunlavey Mar 20 '12 at 12:24
  • Okay, so let's say 90% of startup time is spent in 10 methods, eg localization or string-operations etc. The profiler will show you this right away (*regardless* of their call-tree or "levels deep"!) and you can ideally optimize them to nothing. It's true that some other methods will then become dominant, but I honestly fail to see why you think they would remain "missed": with the 10 methods optimized away the new dominant ones would simply be at the top of the list now, ready for you to take on and investigate and optimize. – Richard Flamsholt Mar 20 '12 at 21:31
  • @Richard: Because what I see is maybe 20 methods with % from 20 - 90. Look at each one. Ones high in the call tree - they're just doing what needs to be done. Ones low in the call tree - same thing. Middle - (apparently) same thing. Conclusion: no obvious way to speed up the program. BUT, look at moments in time and understand what each one is doing and why. Look at the lines of code on the stack, that tell you why. Display values of variables. You WILL see something you don't really have to do. If seen on **two (2)** occasions, it will give you a good speedup. As I said, *try it*. – Mike Dunlavey Mar 21 '12 at 12:51
  • Same strategy here, only using EQATEC Profiler :-) In your example the profiler would *immediately* show that 50% total time is being spent in the low-level resource-string method X. X would be in focus and I'd look at the callers (shown to the immediate left of X) and their callers (each just one click away) etc, figuring out by code-inspection why this call is so expensive and/or being called so many times. It's the same approach, but I would just let the profiler point me straight to the culprit. – Richard Flamsholt Mar 23 '12 at 08:20
0

As of the current version 3.8.14: No, that's not possible. It would be a wonderful refinement, but it's not on EQATEC's immediate roadmap.

Richard Flamsholt
  • 693
  • 5
  • 12