could it be possible to show the actual time spent instead of the percentage, though the percentage does help by showing where the maximum time was spent.....but it does not quatify that and hence cannot really see if there is room for improvement in the code.
cheers,
-ryan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I agree. I'm wondering how I can see the relationships between what's happening in the threads. I suspect that if clicking on the exe at the root of the thread tree showed all of the data for all of the threads at once then sorting on the column with the actual times would show what I'm after. Anyway, what it's doing so far is still excellent.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A profiler is the wrong tool for the question you are wanting to answer.
A profiler adds overhead at every function call in every routine. If you want an answer for "what routine is making my program run slow," a profiler is an awesome tool, and the right tool for the job.
If you want to ask "can I improve this routine," you might start with a profiler to see what the routine is spending percentages of its time doing -- to see what calls it is spending most of its time on -- but to evaluate your progress on improving the routine, you really want to use a stop watch across the root of the call stack.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
could it be possible to show the actual time spent instead of the percentage, though the percentage does help by showing where the maximum time was spent.....but it does not quatify that and hence cannot really see if there is room for improvement in the code.
cheers,
-ryan
I agree. I'm wondering how I can see the relationships between what's happening in the threads. I suspect that if clicking on the exe at the root of the thread tree showed all of the data for all of the threads at once then sorting on the column with the actual times would show what I'm after. Anyway, what it's doing so far is still excellent.
A profiler is the wrong tool for the question you are wanting to answer.
A profiler adds overhead at every function call in every routine. If you want an answer for "what routine is making my program run slow," a profiler is an awesome tool, and the right tool for the job.
If you want to ask "can I improve this routine," you might start with a profiler to see what the routine is spending percentages of its time doing -- to see what calls it is spending most of its time on -- but to evaluate your progress on improving the routine, you really want to use a stop watch across the root of the call stack.
I don't agree.
Without the real time spent I cannot see if a routine was really enhanced or something was worst in the context (others routine).