Comments
Sort by recent activity
ANTS is much cheaper. (Although the gap is lessened with the Pro version.) / comments
ANTS is much cheaper. (Although the gap is lessened with the Pro version.)
I see why it's reporting 70 seconds, but I don't think it has to be that way. I assume that by non-profiled child methods you are referring to code that's excluded by the filter (the filter that by default excludes methods that have no source code).
This problem doesn't only affect Main(), then. In fact, any function that makes a call into an external (filtered out) method, either directly or indirectly, would have inaccurate timing.
And I don't think that by following my logic you'd wind up with no time being spent in my source code, unless of course that was actually the case.
I would simply expect it to show that the majority of the time is spent sitting in various parts of the System.Windows.Forms namespace, waiting for events, etc. (You might just say that 70 seconds were spent in "external methods", referring to methods that were filtered out). The remaining time would be the true time spent in my application (or at least the parts of my application that I, with the filter, decided that I wanted to focus on).
Following my logic, I wouldn't have a large number of seconds mysteriously being attributed to the wrong functions.
Perhaps you're applying your filter too early in the profiling process. I imagine that when you filter methods, you're not timing them at all. This seems consistent with the problem.
A better method would be to still time filtered methods (not at a per-line level, of course) and then to simply not display them in the results. This would give you the information you need to determine the correct time. It also increases the flexibility of the profiler because you'd be able to change the filter after the results have already been collected if you wanted to view the results in a different way. / comments
I see why it's reporting 70 seconds, but I don't think it has to be that way. I assume that by non-profiled child methods you are referring to code that's excluded by the filter (the filter that by...
OS: Microsoft Windows XP Professional 5.1.2600 SP2 Build 2600
System: HP Pavilion dv4000 (PC253AV)
CPU: 1x 1.5ghz Intel M processor (single core)
RAM: 512MB
Installed .NET Framework versions:
2.0.50727.42
1.1.4322
More information available here (System Info file, right-click and save somewhere): http://www.adammil.net/adam-laptop.nfo / comments
OS: Microsoft Windows XP Professional 5.1.2600 SP2 Build 2600
System: HP Pavilion dv4000 (PC253AV)
CPU: 1x 1.5ghz Intel M processor (single core)
RAM: 512MB
Installed .NET Framework versions:
2.0.5...
This is just a wild guess on my part, but here it is:
Do you guys use the RDTSC x86 instruction to retrieve the "time"?
That's not reliable. For one thing, it's not likely to work properly on machines with multiple CPUs because because whenever a thread switches CPUs, your timings will probably get screwed up. They may even become negative.
Second, modern laptop CPUs can alter their clock rate. For instance, during periods of low CPU usage, my laptop's clock rate may be only 33 mhz or something. This is of course done to save power.
With a variable clock-rate CPU, you obviously can't rely on RDTSC to provide wall-clock timing.
Just a guess,
-- Adam / comments
This is just a wild guess on my part, but here it is:
Do you guys use the RDTSC x86 instruction to retrieve the "time"?
That's not reliable. For one thing, it's not likely to work properly on machi...