octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Patch, Profiler] Profiling of operators


From: John W. Eaton
Subject: [Patch, Profiler] Profiling of operators
Date: Fri, 29 Jul 2011 14:02:55 -0400

On 29-Jul-2011, Daniel Kraft wrote:

| this patch implements profiling of operators.  It was not that hard,
| after all ... only now the profile_data_accumulator *only* works on the
| strings identifying functions and never octave_function references.
| This is necessary because (AFAIK) operators don't have any
| octave_function corresponding to them.  But it seems to work the way it
| is now.
| 
| I excluded short-circuit operators, but that is hopefully ok.  The
| problem with those is (as mentioned in a comment) that evaluation of
| operands and the operator itself is entangled and thus I didn't see
| where to start/stop timing the operator to make it reasonable.
| 
| Does this look good?  Then the next step is anonymous functions.

Would it be better overall to change the interpreter so that operators
are simply converted to function calls?  Then you wouldn't have to do
anything special to handle profiling for them.  Also, I think it would
fix the problem pointed to by this comment in do_binary_op in ov.cc:

      // FIXME -- we need to handle overloading operators for built-in
      // classes (double, char, int8, etc.)

The problem is that given a function called @double/plus.m, an
expression involving addition of doubles should invoke the
user-defined @double/plus function for an expression using "+" but
currently Octave only does that if you call plus explicitly, not if
you use the operator form of the expression.  So I think having the
parser convert the operator expressions to function calls would be
cleaner than what we currently do.  I could help with this change.

If you are using function names in the profiler data map to index
functions, does it work correctly for overloaded functions that are
defined for classes?

What happens when a profiling is started, a function is called, then
the load path is modified so that a new function with the same name is
found in a different directory?  Does the current profiler handle that
correctly and accumulate times separately for the two functions with
the same name?

jwe


reply via email to

[Prev in Thread] Current Thread [Next in Thread]