6 Replies Latest reply on Jun 25, 2016 4:31 AM by Nikmolchanov-Oracle

    collect/analyzer: Obtain function trip count?




      In investigating a repeatable slowdown I'm seeing some functions float to the top on my analyzer report.


      However I'd like to understand if these functions are somehow executing more slowly than they should when the slowdown hits, or if I see them only because they are being called too many times.


      Thus, is there a way to tell collect to also gather DTrace-style execution statistics for specific functions?  (i.e. directly counted, not periodically sampled.)


      Thank you!


        • 1. Re: collect/analyzer: Obtain function trip count?

          Please check out "collect -c on ...". That may give you what you are looking for.

          • 2. Re: collect/analyzer: Obtain function trip count?

            Hi Raj,


            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.)



            • 3. Re: collect/analyzer: Obtain function trip count?

              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

              Run application

              % <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 :


              <COMPILER>/bin/analyzer  test.<n>.er


              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)



              • 4. Re: collect/analyzer: Obtain function trip count?

                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.

                1 person found this helpful
                • 5. Re: Re: collect/analyzer: Obtain function trip count?

                  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. 

                  • 6. Re: collect/analyzer: Obtain function trip count?

                    Hi David,


                    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!