Re: First plans on a profiler

[John W. Eaton]

On 25-May-2011, Jordi Gutiérrez Hermoso wrote:

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

It does not work just as well when a static object is involved.  Then
you have to somehow be sure that the initialization happens at the
right time, and that can be problematic because you have no control
over the order of initialization of file-scope or global static
objects.  We've seen this kind of problem before where Octave crashes
at startup on some systems and not others due to some object being
instantiated in an order that we didn't expect.

| 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.

If they are global objects that may be used at any time during the
execution of the program and their expected lifetime is the entire
lifetime of the program, then I don't see that these are really memory
leaks.  Maybe that's what you meant to imply with your quotation
marks?  If so, then why worry about them?

Here is a list of all the singleton objects in Octave that I could
find (I grepped the .cc files for "instance = 0") and that might give
rise to these "memory leaks":

  path searching class
  command history
  fftw planner info
  file directory separator character info
  sparse matrix parameters
  machine info
  random number generator state
  execution environment info
  command editor
  debugging breakpoint table
  font manager
  comment buffer for parser
  interpreter call stack
  symbol table info
  list of dynamically loaded functions
  list of figure objects
  function load path info
  list of graphics handles
  graphics display info
  pager output stream
  diary output stream
  list of other i/o streams
  list of child processes

All of these involve initialization of static global data in one way
or another.  Once instantiated, I think all of them should exist for
the entire lifetime of the program.

For me, the singleton idiom is a useful way of managing these global
objects and avoiding initialization issues.  The nice thing is that
the initialization is neatly encapsulated in the instance_ok method
and the global data is hidden inside a class so we have some control
over how it is used and it is not possible to accidentally instantiate
multiple symbol tables, for example.

But if you see a better way of managing these objects, then pick one
and submit a patch showing us how it should be done.

jwe