Why does declaring a global variable take so much time?

I have a function in from a larger program that I profiled in order to try and find some places to gain some speed. The global declaration in the function below takes up by far the most time. Can anyone tell me why this would take so much time and suggest possible solutions? Unfortunately, giving it as an argument to the function is not an option.

1 Comment

"As far as I was aware ode45 needs an ode function that has just two arguments."
"However, looking a bit deeper, there is a way to pass more arguments."

Sign in to comment.

 Accepted Answer

Just a quick test:
num = 100000000;
tic
a = 1;
for ii = 1:num;
a = ii;
end
toc
global b;
b = 1;
for ii = 1:num;
b = ii;
end
toc
The problem with allocating globals is that ALL programs that are running must be made aware: "Look here, I'm a global and I demand your attention", so that's an overhead. All the normal tricks that a program could do to optimize the use of normal arrays go out the window when you make them globals. Also, and maybe this is not applicable here, good luck making your program thread safe. The solution:
  1. Don't use globals, but you don't want to hear that
  2. Pass them explicitly, something else you don't want to hear.
  3. Don't modify them so often.

3 Comments

Thanks for the quick response.
In my program, the global P is an nx2 matrix that is set at the beginning of the program and after that only read from, never changed. It only needs to be accessible to two functions, one that sets its values and the other as shown in the original post. The setter function doesn't view it as a global variable; the functions output is used by the script to set the value of the global. The function above is the child of a function that I can't change the arguments for.
As such, either I have P declared as a global in the child function, as I do now or I have P declared as a global in the parent function (which is called just as many times as the child functions) and pass it as an argument to the child. I don't belive the latter is any better than the former.
I don't know of another way to make the variable accessible to the child function.
You might only need it to be accessible to two functions, but there is no way for Matlab to know that.
"The setter function doesn't view it as a global variable". Are you sure? You only need declare global once. All subsequent call will treat a variable with that name as global. There is no way to make a global local again, if you understand what I mean.
Well, if you can't change the parent function (why?) then I can't think of any other way of passing the values of P to the child. Not one that is straightforward and safe that is.
Thanks again for the response.
My understanding was that you needed to declare global in every function that wants to use that global variable (which I assume is matlab's way of getting around accidentally overriding things). Certainly, if I take out the "global P" line from the function shown in my original post I get an error: "Undefined function 'P' for input arguments of type 'double'."
Sorry I was ambiguous with the line "The setter function doesn't view it as a global variable". What I meant was, the setter function doesn't write directly to the global variable, infact it has no interaction with the global variable so my original statementt that it is one of two functions that accesses it is incorrect. What actually happens is the output from the function is used in the script to set the global variable's initial value.
The function that actually uses the global variable is called by a function that is called by the ode45 solver. As far as I was aware ode45 needs an ode function that has just two arguments. However, looking a bit deeper, there is a way to pass more arguments. Problem solved. No more globals.
Thank you very much for your help.

Sign in to comment.

More Answers (1)

Try mechanisms such as
setter: setappdata(0,'P', P);
your function: P = getappdata(0, 'P');

4 Comments

Isn't that like putting makeup on a global to make it look pretty? :) Also it would involve modifying the parent function, which Alexander apparently can't. Or am I missing something?
It isn't just putting makeup on if it runs faster. I have not timed it so I do not know what the relative speeds are.
That might well be, but it would have the disadvantages of a global, save that you need to explicitly call it. Might make debugging a pain. Oh well...
One of the problems with global variables is that people accidentally reuse the name for local purposes, thus overwriting the global version. If the only way to overwrite the global version is to code a setappdata() call, then that is not going to happen accidentally.

Sign in to comment.

Categories

Find more on Programming in Help Center and File Exchange

Asked:

on 10 Feb 2014

Commented:

on 13 Aug 2020

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!