Re: Follow up on profiler development

[John W. Eaton]

On  9-Aug-2011, Daniel Kraft wrote:

| > Can you in fact provide some gprof output (run a few demos or tests) 
| > and make sure that the profiling code functions are all very low in 
| > the profiling output? Let me know if you manage. I had some trouble 
| > writing profiling instrumentation data into the Octave binary with 
| > gprof, so I used oprof instead. If you also have trouble with gprof 
| > try with oprof, but I would like some reassurance that we are not 
| > slowing things down.
| 
| I'll try to do this after data collection for hierarchical profiles is
| done; then the backend should be complete (in a first stage at least),
| even if we still play around with the UI to hierarchical data.  And
| thanks for the hints with gprof -- I'll try it, but if I fail I'll try
| with oprof.

If instead of

  {
    profile_data_accumulator::enter pe (profiler,
                                        profiler_name ());
    cmd_list->accept (*current_evaluator);
  }

we wrote something like

  {
    if (profile_data_accumulator::active ())
      profile_data_accumulator::enter pe (profiler, profiler_name ());

    cmd_list->accept (*current_evaluator);
  }

and

  profile_data_accumulator::active ()

could be inlined, then I'm fairly certain that the profiler would have
negligible effect on performance since it would only require the
testing of a flag when profiling is disabled.

jwe