A few years ago I used a Profiler (I forget the name) on my Delphi code at
the time and got fantastic results showing both:
a) lines of code that took the longest to execute and
b) lines of code that allocated the most unreleased memory.

I have looked around and am unable to find a good tool to easily achieve
these statistics for my C# Winforms application. Possible reasons are that:
1) I am having difficulty finding the existing functions in a tool thet supplies
them or
2) I have not yet found the tool that does actually supply them.

I also wonder if my statistic b) above is no longer able to be profiled because
dotnet has a garbage collector whereas Delphi did not? Some of them seemed
to say that to observe changes in memory allocation over time I needed to
take "snapshots". However I can't see how that will help me with that specific
requirement anyway.

The profilers I have looked at are:-
* ANTS Profiler
* AQTime
* CLR Profiler
* ProfileSharp
* SilkTest
* YourKit

Am I on the right track or have I missed the right product?

Any advice on which direction you think I should go (more time understanding
or more time downloading) would be much appreciated.

cheers,
Paul

Hello,

> The profilers I have looked at are:-
> * ANTS Profiler
> * AQTime
> * CLR Profiler
> * ProfileSharp
> * SilkTest
> * YourKit

* dotTrace?

> I also wonder if my statistic b) above is no longer able to be profiled
because dotnet has a garbage collector whereas Delphi did not?

The CPU profiler helps with finding the functions (not lines of code, but
functions) which take the most execution time. The profiler would collect
statistics for some period of time. After that, you can see the share of
that time each function took, in percent, and whether that time was spent
within the own code of that function, or rather in a call to some other function,
in percent again. By tracking down the tree of function calls, starting with
the thread node that is assumed to run 100%, you determine the bottleneck
functions that take, say, 75% of your application startup.

The memory profiler tracks the creation and lifetime of the objects. In .NET,
you cannot have an old-style memory leak (as Garbage Collection would reclaim
the no-more-needed objects), still it may so happen that an object is erronousely
prevented from being collected. Someone may be still holding a reference
to the no-more-needed object, effectively marking it as “alive”, and that's
the main issue to be tracked down in memory profiling. You cannot readily
tell such references from normal ones, so you'd be making those “snapshots”
to hunt it down. First, you run the application being tested for some time,
so that all of the lazy-init happened. Then you take the first snapshot,
“before”. After that, you perform a series of actions, like opening windows,
running operations, etc, and then return the app to the same state as when
taking the first snapshot (close the new windows, …). Logically, it should
take no more memory than before, if there are no leaks (save for caches).
At this point you take the second snapshot, “after”, and make the profiler
show you the difference. Those are the potential leaks. For each such object,
you can see the line of code that created it, and the objects that are holding
a reference to it and preventing it from being collected by GC.

Basically, that's it.

(H) Serge

On Dec 2, 1:00 am, Paul Ritchie <REMOVEpritc...@xtraREMOVE.co.nz>
wrote:
[....]
>
> The profilers I have looked at are:-
> * ANTS Profiler
> * AQTime
> * CLR Profiler
> * ProfileSharp
> * SilkTest
> * YourKit
>
> Am I on the right track or have I missed the right product?
>

nprof ?

-- Henon

----
my site: http://www.eqqon.com