Hi,

I've been playing around with the command-line profiler a little bit and I have some questions:

1. Is there any way to turn off the summary of results? I've tried the /q switch but it doesn't turn it off.
2. The XML output has the PIDs for the elements - is it possible to get the TIDs as well? This would be especially useful for the calltree.
3. I've used the /ows switch to limit the output, but I am still getting several methods in the Microsoft.Win32 which do not have source code - this the expected behaviour?
4. I have tried the /ll but I can't see any difference in the output between having it and not having it - what differences should there be?

I'm still playing around with it, but these are my initial issues.


Craig
csut017
0

Comments

3 comments

  • Andrew H
    csut017 wrote:
    Hi,

    I've been playing around with the command-line profiler a little bit and I have some questions:

    1. Is there any way to turn off the summary of results? I've tried the /q switch but it doesn't turn it off.

    Not at the moment. The report is written out when /q is turned on as it's the only way to get the results when no other export options are set: possibly we should change this behaviour so that it's only output if /q is turned off or if there are no other reports to be written out.
    2. The XML output has the PIDs for the elements - is it possible to get the TIDs as well? This would be especially useful for the calltree.

    Not as things stand. Would you prefer a format that separates out the threads into different call trees or just appends a list of the thread IDs to the method entries?
    3. I've used the /ows switch to limit the output, but I am still getting several methods in the Microsoft.Win32 which do not have source code - this the expected behaviour?

    Yes: these will be unmanaged calls that get recorded regardless of how that setting is set. This setting changes what the profiler instruments rather than the output - instrumenting fewer calls improves the performance of the target application and increases the accuracy of the profiling results (but can make it less clear what's going on).

    Unmanaged calls work slightly differently: the profiler can't choose which ones it gets notified about, so it reports them all.
    4. I have tried the /ll but I can't see any difference in the output between having it and not having it - what differences should there be?

    This tells the profiler to perform line-level instrumentation on methods that have debugging data associated with them. None of the reports currently report on this: it produces a lot of data and it isn't clear how to present it in a flat file in a way that would be useful.

    This doesn't mean the option is totally useless, as the main ANTS UI can display this information if you use the /data: option to save out a file it can read.
    Andrew H
    0
  • csut017
    Thanks Andrew,

    #1, either approach would be good - I definitely think something is needed to turn the output off as it will confuse external tools.

    #2, I would prefer different call trees - this would show clearly what is happening within each thread.

    #3, while this is slightly annoying, I guess we can filter it out ourselves (I am assuming the only elements that have the has-source tag are those elements from our code.)

    #4, will it would be nice to have the line timings in the XML, I see the they are not always in the UI version either, so I can live with it.

    Some extra data that would be helpful would be start/end time in the call tree. This combined with having different call threads per thread would allow us to see what is happening in the different threads at the same time. Would this be possible?


    Craig
    csut017
    0
  • csut017
    Hi,

    A quick request - is it possible to include the source file in method information?


    Craig
    csut017
    0

Add comment

Please sign in to leave a comment.