Global variables - is there something better?

13 views (last 30 days)
I have a large structure; contains test and parameter descriptions and a large (2M+ Rows X 100+ Columns) matrix. I need to read from this structure using multiple functions (some function multiple times). The structure is large enough that I don't want multiple copies in memory. Most functions will read only, but some may create new columns that will need to be added to the current matrix. This structure always has the same name and structure (data matrix will vary) so I'd like to write functions to simply read from it but all I read is AVOID GLOBAL VARIABLES.
  1 Comment
per isakson
per isakson on 5 Oct 2017
Edited: per isakson on 5 Oct 2017

Sign in to comment.

Accepted Answer

Cedric Wannaz
Cedric Wannaz on 5 Oct 2017
Edited: Cedric Wannaz on 5 Oct 2017
An OOP approach would also be interesting in the sense that you could implement specialized methods for operating on your data structure and maybe even overload some operators to fine tune how they operate.
If you don't want to go for OOP, then nested functions could be a good alternative to globals:
function buildAndProcess( locator, flag )
largeArray = load( locator ) ;
process1() ;
if flag
process2() ;
end
% === Nested Functions ===
function process1()
largeArray(:,end) = ... ;
end
function process2()
largeArray(end,:) = ... ;
end
end

More Answers (1)

Walter Roberson
Walter Roberson on 5 Oct 2017
There is no way to avoid having multiple copies of a data item in memory if you are adding more data to it: it is always necessary to find new memory large enough to hold the combined results, copy the data out of the existing item into the new data item, and then copy as well the new values in as well.
You can avoid this by pre-allocating the data item as large as it could possibly get. You can reduce the impact of this pre-allocation if what you make the data type cell, or structure array (pre-allocated to the maximum number of possible entries), or table, or containers.Map: all of those data types essentially internally contain a number of pointers to chunks of data and in some circumstances only the one chunk has to be copied to update it (or, at most, copies of the pointers need to be made rather than copies of all of the associated data.)
It sounds as if perhaps your added columns do not always have the same meaning: if that is the case, then a struct or a table or a containers.Map might make a lot of sense, giving you the ability to name the item and retrieve it by name.
You might also see reference to handle variables. Only one copy of a handle object exists -- except during the time that it is being modified, at which point it has the same rules about having to allocate / copy when the size changes. It might, however, make some sense in your program to create your data as an "object" with a number of different named properties -- which is internally implemented as a struct and so modifying one property does not require deep copies of the memory for another property. This would give you the same named-item advantages I mentioned for struct and table and containers.Map

Community Treasure Hunt

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

Start Hunting!