Re: [Patch] Profiler update, interface function

[Jordi Gutiérrez Hermoso]

2011/7/14 Daniel Kraft <address@hidden>:

> after today's discussion, here's an update for my profiler.  I
> greatly extended the data collection done in
> profile_data_accumulator, and also added a .m-file function which
> provides 'profile' to the user.

Thanks, as we've talked about, this has already proved useful.

> I hope that the new data collection (which looks through the
> call-stack and also keeps track of child/parent functions) is not
> too expensive to do at possibly every function call; what do you
> think? But I don't see how we could do it any other way and still
> get the output Matlab gives.

It seems to be working fine right now. If the profiler itself is too
slow, we can optimise it later. Don't worry too much about this point,
but concentrate instead on getting more functionality in. We can
always polish later. First make things work.

> BTW, IsRecursive in my patch returns true iff at some point, the
> function called was already somewhere on the call-stack; so foo
> below will be recursive:
>
> function r = foo (a)
>  r = bar (a);
> end
>
> function r = bar (a)
>  if (a == 0)
>    r = 1;
>  else
>    r = a * foo (a - 1);
>  end
> end
>
> Or should only functions be recursive where the function itself is a
> direct parent/child? The implemented behaviour seems more
> reasonable to me

It does to me too.

> but I don't know what Matlab does.

Neither do I. I'll ask around. Or someone who is watching this, can
you tell us if Matlab considers this a recursive function or not?

> What do you think about this patch?

Looks good.

> Besides obviously correcting it for things that turn up, I think
> I'll try to look into profiling of operators and fixing the
> anonymous functions next. Hm, or maybe implement a flat-profile
> "nice" output routine first, because without one, I don't think the
> current profiling information is of much use to an end-user in the
> structure format at the moment.

I don't know if you've already made up your mind about this point. I
would personally be interested in more detailed profiling information
before you work on improving the presentation of the information
you're already collecting, but either of these tasks seem useful, so
work on the one that you find more interesting for now.

Alternatively, if you have the fortitude, tackle the difficult
problems first: collecting information for anonymous functions and
operators. I don't think Matlab profiles operators, btw, so this could
definitely give Octave a competitive advantage. ;-) I don't see a
reason why operators shouldn't be included in profiling, since they
are functions like anything else but with a peculiar syntax.

- Jordi G. H.