[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: First plans on a profiler
From: |
John W. Eaton |
Subject: |
Re: First plans on a profiler |
Date: |
Wed, 25 May 2011 12:17:40 -0400 |
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