topic Efficiency of Script for speed in GDL

Efficiency of Script for speed

GDL Enthusiast — Thu, 26 Sep 2024 11:06:32 GMT

Hi,

I have created an object that is quite slow on loading and changes. I read in the past about speeding up script by using a _ before a variable to constrain the the GDL reader to only look for a variable within that page. Does this speed up the processing time? Are there any other ways to speed up the processing time of the script?

For the _ addition before a variable, is it true that it works only in the same page of the script e.g. when in the Masterscript page:

variable1 = input1 ! Would this search all pages including Master, 2D, 3D, Parameter, Interface pages?

variable1 = _input1 ! Would this search only within the Master page?

Many thanks in advance, Matt

Re: Efficiency of Script for speed

Barry Kelly — Wed, 08 May 2024 01:03:09 GMT

@GDL Enthusiast wrote:

I read in the past about speeding up script by using a _ before a variable to constrain the the GDL reader to only look for a variable within that page. Does this speed up the processing time?

I have not heard of this.

As far as I know, it will not make any difference, and is just a naming convention so you can easily tell in the script that it is a parameter.

The question is, why do you need to state that variable1 = input1 ?

If that is always the case then just use input1.

But if somewhere else in the script variable1 = input2, then that could be a valid thing to do.

As for the efficiency of your script, it is really hard to say without seeing it.

One thing I can recommend is to do all calculations once in the master script.

All script will refer to the master script, so there is no need to perform the same calculations in 2D, 3D and other scripts.

Barry.

Re: Efficiency of Script for speed

Nader Belal — Wed, 08 May 2024 09:06:18 GMT

tl;dr You have got everything wrong, but luck prevented that library part from reporting an error. Period.

Long Version,

Learn the difference between Parameters and Variable, both are the same, but their scope is different.
The underscore "_" and the double-underscore "__" is a styling convention for GDL script, where the underscore "_" prefix is to indicate that this is a variable, and the double-underscore "__" prefix is a variable within a subroutine. Also return to point 1.
Speed issue. You simple have got so lucky to get the results that you have got. Usually these changes cause the GDL Editor to throw errors because the script would not work.
Unless you have hit some of the old (really old) parameters that GDL can get out the program (which I don't believe you have done), then you were quick lucky (see point 3), and even then, those parameters use the tilde as a prefix " ~ "

Re: Efficiency of Script for speed

Barry Kelly — Wed, 08 May 2024 09:13:14 GMT

@Nader Belal wrote:

Unless you have hit some of the old (really old) parameters that GDL can get out the program (which I don't believe you have done), then you were quick lucky (see point 3), and even then, those parameters use the tilde as a prefix " ~ "

Do you mean the old GLOBAL variables?

If so, that is the suffix and not the prefix.

And they can be either underscore _ or tilde ~

A_ = GLOB_SCALE

A~ = WALL_FILL

Barry.

Re: Efficiency of Script for speed

Nader Belal — Wed, 08 May 2024 17:37:53 GMT

May be. I was talking out of my memory without consulting the Manual

Re: Efficiency of Script for speed

GDL Enthusiast — Wed, 08 May 2024 20:10:46 GMT

Thank you so much for your response Barry. I am glad I didn't go down the road of using _ to speed up the script and all the work the renaming! Best regards, Matt

Re: Efficiency of Script for speed

GDL Enthusiast — Wed, 08 May 2024 21:34:22 GMT

Hi Nader,

I like the tl;dr, haha it doesn't surprise me 😁

Thank you for all the points, super helpful! I am glad to know the underscore "_" and the double-underscore "__" doesn't keep it local. Saved me a mountian of recoding!

Best regards, Matt

Re: Efficiency of Script for speed

Nader Belal — Thu, 09 May 2024 07:59:38 GMT

Variables can and will be local if they are bounded within a subroutine, unless they were predefined (or initiated) before the definition of a subroutine