Any ability to profile part of an application?

I'm just trying out ANTS 4 - while the UI is very slick, my initial impression is that ANTS is too intrusive to use on a program of any size.

The problem is, it's an all or nothing affair, as far as I've learned so far. Is there any way to start collecting profile information only once a certain function is hit? Or when I click a button on the profiler UI? Or the ability to attach to a running program, so I don't have to profile the startup?

Comments

  • Hi,

    there are a few things you can do -

    1. Use a less detailed mode of profiling to make profiling quicker. So instead of line level, choose the method level (only methods with source) in the setup dialog.

    2. The timeline has been designed to let you only see parts of your code. So you can simply click and drag on the timeline over a period of CPU activity and it will only show you the methods that were executed for that period of time which is a very simple way of cutting out info you don't want to see and concentrate on methods you do want to see.

    3. Use the profiler dll so add a reference to RedGate.Profiler.UserEvents.dll in your project. Then in code you can write something like:
    RedGate.Profiler.UserEvents.ProfilerEvent.SignalEvent("My method was hit")

    This will show up in the timeline in the events bar so you can clearly annotate your timeline with things you are interested in.

    Attaching to a running process is a feature we are aware would be of benefit and are considering this for future releases. Hopefully these options will allow you to do everything you wish to.

    Regards,

    Stephen
  • As Stephen said, using a less detailed profiling mode will help a lot - in particular turning off line-level timing.

    One other thing that might help is to turn on the 'enable inlining' option in the options dialog: this does reduce the detail that the profiler can record but can have a significant effect on application performance. We're changing this to be the default in version 5.
    Andrew Hunter
    Software Developer
    Red Gate Software Ltd.
  • Unfortunately, those tips don't appear to help. I'm already using a less detailed profiling mode.

    The timeline is cool, but the impact of the profiler is so profound that getting to the point in my app that I actually want to examine takes 5+ minutes when running under the profiler versus a few seconds when not running under the profiler. That doesn't make for a very pleasant experience.

    Using the DLL to raise a named event doesn't sound like it'd help either - I can easily find the time of interest using the timeline - it's the painful process of running the program up to that point that I'm trying to avoid.

    I'll keep my fingers crossed for attach to process and/or other ways to turn profiling on/off in future version.

    I will try the "enable inlining" option to see if it makes an appreciable difference!
  • I'm really surprised that the profiler is having anywhere near that sort of impact. With the low impact mode I've never seen it have any sort of signicicant impact.

    Did enabling inlining make any difference?

    Stephen
  • That certainly does sound like an unusually high amount of overhead.

    Are you using a virtualized environment? Some VM implementations don't provide a very efficient way of reading the CPU time stamp counter which can have a negative effect on the performance of the profiler. A warning is written to the log file if this is detected.

    On XP you should be able to find this in C:\Documents and Settings\<user name>\Local Settings\Application Data\Red Gate\ANTS Performance Profiler 4. The message will read something like "Profiler overhead calculated as 2435 ticks when making a method call, and 2300 ticks to the method prologue/epilogue. These values appear to be too high, so corrections made to this data may not be very accurate." (Running natively, the overhead is typically around 10-80 ticks depending on CPU type, and no message is added if it is in this range)

    Also, are you using .NET 1.1? The profiler API available in that version of .NET is much less efficient than the one introduced into .NET 2.0. For many applications you can work around this by forcing them to run using the .NET 2.0 framework while profiling using an application config file.
    Andrew Hunter
    Software Developer
    Red Gate Software Ltd.
  • StephenC wrote:
    I'm really surprised that the profiler is having anywhere near that sort of impact. With the low impact mode I've never seen it have any sort of signicicant impact.

    Did enabling inlining make any difference?

    Stephen

    Enabling inlining did not have much impact - I'd have to time it to get a better feel, but it wasn't dramatic.

    A little background: The application is a specialized document editor, and i'm trying to profile a certain feature that requires an open document, looking specifically at the behavior when I have a large document open. Opening a document does some soundness checks on the document which results in several seconds of CPU-bound execution including millions of function calls on a fairly deep call stack (but only the bottom couple frames of the stack are "in motion").

    So, the amount time taken to gather profile data for that path may be reasonable - but at the moment I don't care about it, hence my desire to start profiling later in the applications execution.

    Previously, I've profiled this app using the VSTS profiler where I'd generally start with a sampling profile session and then when I've identified an area that needs work, I'd build a special-purpose driver program that would exercise only that area and run that program using the instrumented profiler. It's not ideal, and I'd hoped that ANTS would let me avoid having to build special purpose profiling drivers, but without the ability to start mid-way through a program invocation, I don't see that happening.
  • AndrewH wrote:
    That certainly does sound like an unusually high amount of overhead.

    Are you using a virtualized environment? Some VM implementations don't provide a very efficient way of reading the CPU time stamp counter which can have a negative effect on the performance of the profiler. A warning is written to the log file if this is detected.

    On XP you should be able to find this in ...

    Windows Server 2003 R2 Enterprise Edition SP2, x64, dual-dual-core Xeon w/8GB of RAM. I'm running several VMs on the machine, but they're just idle and not involved.

    I did find the log file - no mention of reading the CPU tick counter taking a long time.
    Also, are you using .NET 1.1? The profiler API available in that version of .NET is much less efficient than the one introduced into .NET 2.0. For many applications you can work around this by forcing them to run using the .NET 2.0 framework while profiling using an application config file.

    .NET 3.5 SP1 (although the program in question is only using .NET 2.0 functionality).
Sign In or Register to comment.