dim[10][10] or 100 parameters ?

[gaba]

A quick technical question 😎
What is more efficient on the stack/memory side of GDL:
- a 10x10 array (i.e. 100 cells)
- or 100 parameters
?
I'm not asking about the convenience of use in a script.

[Barry Kelly]

I am sure that has  been asked here a long time ago, or maybe it was another forum.

If I find it i will let you know.

I don't have a technical answer for you, but I don't think you will notice much difference.

There is a physical limit to the number of parameters an object can have, I believe it is 1064?

Some of the doors and windows are approaching that limit from what I have read here before.

So if you can use an array then that is probably better in that it will free up possible parameters.

But speed/memory wise, I don't think you will notice a difference.

I guess the only way to find out for sure would be to try it.

Barry.

[Barry Kelly]

I did find this one post...

https://community.graphisoft.com/t5/Libraries-objects/Passing-parameters-to-macros-and-effectivity/m...

Barry.

[Lingwisyer]

Sounds like a question for @Peter Baksa .From the code execution side, I would have figured that an array would have been more efficient, on the scale of milliseconds, given the number of statements requiring processing, though I guess it depends on how you are querying, and how efficient the language is itself. It's no C++... 

[Peter Baksa · Accepted solution]

On memory side an array takes less space, because each parameter has its own name and description, an array only one. Using different parameters, the script itself is longer too.

[gaba]

Barry Kelly, Lingwisyer, Peter Baksa thank you for your interest.

My reflection in this topic basically concerns LIBRARYGLOBAL, and to some extent refers to what Mario Sacco wrote recently:
https://community.graphisoft.com/t5/GDL/Ask-a-MVO-setting-more-parameters-with-a-single-command/m-p/...

1. Taking over individual MVO parameters
(here the parameters can have DIFFERENT types of INT/REAL/STR/BOOLEAN...), simple example:

x = LIBRARYGLOBAL (mvo_macro_gsm, "mat11", mat11)
...
x = LIBRARYGLOBAL (mvo_macro_gsm, "mat25", mat25)
x = LIBRARYGLOBAL (mvo_macro_gsm, "mat26", mat26)
x = LIBRARYGLOBAL (mvo_macro_gsm, "mat27", mat27)
...
x = LIBRARYGLOBAL (mvo_macro_gsm, "mat1010", mat1010)

2. Taking over an array from MVO
(of course the array must have a SPECIFIED content type of INT/REAL/STR/BOOLEAN...), simple example:

dim dimmat[10][10]
x = LIBRARYGLOBAL (mvo_macro_gsm, "dimmat", dimmat)

mat11=dimmat[1][1]
...
mat25=dimmat[2][5]
mat26=dimmat[2][6]
mat26=dimmat[2][7]
...
mat1010=dimmat[10][10]

I think that for a small number of parameters, method 1 is OK. For a larger number of parameters, method 2 may be better, but requires more discipline, e.g. in terms of parameter types and the structure of row and column numbers to take the appropriate parameter values from the array.
Since LIBRARYGLOBAL was released, I've been creating a lot of objects using MVOs. Unfortunately, this causes the number of tabs in the MVO to grow and they don't fit on the screen. So my long-term strategy is to use my own MVO container that combines sub-MVO settings. This causes the container to contain a lot of parameters (around 650 so there is still a supply of up to 1000...). So I'm increasingly creating some sub-MVOs using arrays instead of standalone parameters. Arrays, while somewhat limited, allow for easier scaling of data with new ideas.
Currently, MVOs are the only way to globally change some finishes on objects, because the graphic replacement rules are completely inadequate for this.