Re: [Patch, Profiler] Profiling of operators

[John W. Eaton]

On 29-Jul-2011, Daniel Kraft wrote:

| The current implementation (with the patch) also does nothing special
| for operators -- it just handles everything based on the string.
| 
| IIRC, using the name instead of the function object (resp. its address
| or something similar) was what you recommended in the beginning.

OK.

| I don't know about overloading -- so yes, probably the profiler is
| currently fooled if two different functions have the same name (I never
| used that myself in Matlab/Octave code and am not really familiar on how
| you would go for an overloaded method).
| 
| Do you think we should switch back and use the octave_function objects /
| pointers instead for identifying functions?  Or continue with the names?
|  But also for the user it does not make a lot of sense to display two
| functions with the same name; how should (s)he now which is which?
| 
| Actually, it's not the function name which is used but
| octave_function::profiler_name() -- so I suppose the best way to handle
| overloads would be to make this function return something like
| "myfunction(double)" vs. "myfunction(int8)" instead of just
| "myfunction".  Then it is both clear to the user what an entry means and
| also the string can again be used as identifier of the function for
| collecting data.  Does that make sense?

I think it would be OK to just use the full name of the function,
including the directory name where the .m file is defined.

I took a quick look at having the interpreter convert operators to
function calls and it is not as simple as I thought it would be.
Things that will require some thought are how to deal with constant
folding, what to do about Matlab-style short circuit evaluation for |
and &.  Also, since we don't have pass-by-reference semantics for
function calls, I don't think we can allow overloading for increment
and decrement operators.

jwe