Please check out "collect -c on ...". That may give you what you are looking for.
I had forgotten about the "-c" option. Thank you.
Though this seems pretty heavyweight. But maybe that's unavoidable. Anyway, I can't seem to get it to work.
After some wrestling with the fact that "collect -c" wont work with -F (follow) after capture I got the error:
"bit (error): No instrdata file for main target"
Also, it seems to slow down the app startup pretty significantly. Is there a way to specifically target the scope of examination? (certain group of statically linked objects, just function-level data, etc.)
We will look into the possibility of supporting "collect -c on -F on "
We would like to investigate the "bit" error that you are seeing. Could you please try using the internal tool "bit" as follows :
You can find "bit" in <COMPILER_PATH>/lib/compilers/bit.
% cp a.out a.out.backup
% <COMPILER>/lib/compilers/bit instrument -R -M a.out
% <COMPILER>/lib/compilers/bit analyze -e -R -M a.out
You can skip the -M flag if you don't care about profiling shared libraries.
The first step will replace a.out with an instrumented version, so you may want to backup the original a.out.
This will create an analyzer experiment with a name test.<n>.er, where n is a number.
Then you can run "analyzer" or "er_print -func " on it to view the function counts :
Let us know if this works for you.
You can limit the profile counting only to a certain files and avoid profile counting on the other files by using a compiler option.
Use -xannotate=no option to compile files that you do not want to profile.
Use -xannotate=yes option to compile files that you want to profile (-xannotate=yes is the default on Solaris and -xannotate=no is default the on Linux)
1 person found this helpful
There is another way, though it is kind of a workaround. You can insert some calls that "collect" can trace,
for example mutex_lock() and mutex_unlock(). If you insert them into the function that you are interested in,
and then profile using "collect -s all ...", you will see how many times mutex_lock() happened in this function.
Yes, I know, sounds ugly , but it may be simpler that "collect -c on" approach, and it should run much faster.
Just to close this out, the problem was indeed due to excessive function calls and not slow execution.
@raj The manual "bit" command method did not work. Similar errors encountered for both 12.3 and 12.4. Also things like: "bit (error): No Child process (errno = 17) File exists". I can open an SR if you think it's worth trying to understand. Maybe I'm doing things wrong.
@Nikmolchanov This is an awesome workaround! It works great and directly addresses what I was trying to find out. For this case, the mutex_lock() "probe" worked fine as this was single threaded code anyway. I guess there are vast differences technologies (and I see some DTrace super stars moved on from Oracle) but I do hope you guys can integrate better adhoc tracing functionality in to the performance analyzer.
Completely agree, we have to find a simple solution for users who need to know how many times a function was called,
even if they cannot modify its code. Glad to know that the workaround worked for you!