Re: profiler implementation

[Jordi Gutiérrez Hermoso]

On 10 August 2011 11:11, John W. Eaton <address@hidden> wrote:
> Earlier, we discussed using a singleton object that follows the
> pattern of other singleton objects in Octave to implement the
> profiler. Looking at the current code, it doesn't seem to use that
> style, but is just using a single global instance of the
> profile_data_accumulator object. Why?

Heh, I was hoping you wouldn't notice that. I hate singletons, and I
was happy Daniel didn't use one. As I recall, you wanted singletons to
avoid the static initialisation fiasco, but this doesn't seem to be a
problem here.

> The current implementation of the profile_data_accumulator::enter
> object appears to allow data to be collected in multiple accumulator
> objects, but then the code that uses this class, like
>
>  {
>    profile_data_accumulator::enter pe (profiler,
>                                        profiler_name ());
>    cmd_list->accept (*current_evaluator);
>  }
>
> only uses the global profiler object.  It seems to me that this code
> would have to change if you wanted to collect data in a different
> global accumulator object.

You see this as code that has to change and thus rigidity in the code.
I see this as flexibility. If we ever decide to use a different
profiler to profile a different kind of Octave function, we can use
another global object to profile that other kind of Octave function.
The singleton pattern just seems to me like fluff that you wrap around
a global object.

> If you just want a single accumulator object,

But we might not. And while we do want one, the above works fine.

Global objects are fine; I see no point in wrapping a global object
with redundant get_instance() and do_thing() functions.

- Jordi G. H.