On 04/30/2017 10:28 PM, Rik
wrote:
On 04/28/2017
06:17 PM, John W. Eaton wrote:
On 04/28/2017
07:49 PM, Rik wrote:
Is there a
performance issue here? If you start passing too many
arguments to a function, more than can conveniently fit
into the number
of scratch registers that your CPU has, then you have to
pass arguments
on the stack which will slow things down. But I can't
quite tell if you
are suggesting another parameter, or whether you want to
include the
pointer to the interpreter as say the first entry in the
octave_value_list passed as inputs to the function.
Presumably the
octave_value_list is already passed as a pointer/reference
since it
could be large. In that case it wouldn't have an impact.
At first, I thought it would be easier to just add a pointer
to the
interpreter object to the octave_value_list that is passed
to functions.
But it turned out to be difficult to chase down all the
places where it
is needed. There are many locations where it could be
needed and I
couldn't figure out an easy way to get help from the
compiler.
So I started working on passing the pointer to the
interpreter as an
additional parameter to DEFUN functions. It seems much
cleaner this
way. It also means that these functions will now accept
three arguments
instead of two. One is a pointer to the interpreter, one is
a const
reference to the octave_value_list containing the arguments,
and one is
an int for nargout. I doubt that passing one additional
pointer to these
functions will make a big difference overall, but we can
certainly
measure it to be sure.
It's true. I don't think register pressure is going to
develop at 2 or 3
function parameters. I thought we might already be at the 4-5
parameter
range in which case another could make a difference.
If the compiler is no longer doing initialization of the
singleton, is this
the cause of certain data race bugs between the interpreter
and the GUI
thread? Bug #50880 and #50396 both seem to be caused by the
GUI looking
for interpreter static variables that have not been
initialized in time.
Also, if the pointer to the interpreter really is used all
over the code
base, maybe it does make sense to have it be a global? I know
it is
generally frowned upon, but it might actually be simpler then
re-working
the API to pass the pointer through to all functions.
(I wrote this a couple weeks back, but I think JWE had followed
up on Rik's idea. However, a similar issue came up with a post
regarding GUI error colors, so I'm posting this more as a
general reply.)
The global variable idea is frowned upon for good reason.
Global variables get abused for quick fixes which leads to
strange bugs that are difficult to track.
Philosophically "pointer to interpreter all over code base" is
something I've tried to deter because I think it is going the
wrong direction. For example, intermixing of GUI and
core/interpreter is unnecessary, as I feel there is a wealth of
built-in commands that offer up all the information the GUI
needs, if only there were a simple routine to return the result
of an interpreter command (which can be done across a thread by
passing a pointer to an octave_value_list rather than a
reference to an octave_value_list).