Re: First plans on a profiler

[Jordi Gutiérrez Hermoso]

 2011/5/25 John Swensen <address@hidden>:
> I think there are a lot of things in the Octave code that are
> essentially singletons. Grep the source code for all the classes
> with static methods and contain the "instance" variable of the same
> class. There are a significant number of them.

As I understand it, this is no reason to have more of them. Unless you
mean that singletons must be used to interact with other singletons? I
don't think that's true, is it?

By jwe's own admission, he wishes he would have done some things
differently with Octave's code. This could be one such case, even if
jwe doesn't know it yet. ;-)

> I too am not a huge fan of singletons, but they have their place

I've never seen that place. A namespaced global object works just as
well and has less syntactic cruft built around it.

> and since Octave already uses them extensively I don't think one
> more is prohibitive, especially if it is the right choice to fit in
> with how things are done currently. Isn't the profiler going to
> essentially be a modified tree_walker/executer? How are the existing
> classes that do tree walking and executing code implemented. It
> should probably follow the exact same pattern.

It can follow the same path without being a singleton, can't it? If we
can build in extra flexibility at no cost (e.g. making it an ordinary
object), we should.

This is overall a minor stylistic point, though. If everyone else
agrees that a singleton profiler is really the way to go, I will
relent. There is the issue of memory management, but we already have a
bunch of minor "memory leaks" (mostly allocations of small global
objects that last for the entire duration of execution and are never
deleted) that one more probably won't be noticed.

- Jordi G. H.