Does the use of constants yield a performance improvement over using their values?

[Arduenn Schwartzman]

Hi all, does the use of constants yield a performance improvement over using their values? Like using ZERO_VECTOR is recommended over using <0.0,0.0,0.0>? Or is that a myth? I would have sworn I had read something about it somewhere on a Wiki, or in a forum.

[Coffee Pancake]

Bytecode size is the only performance metric that counts for LSL.

Speed and responsiveness are subject to so many external factors as to make them irrelevant.

 

I've not done any tests to see if using the provided consts is smaller than long form alternatives, but I wouldn't be too surprised if it turned out to be the case.

[Quistess Alpha]

there was a discussion in the scripts group recently where people did some basic tests using long variable names (integer aaaaaaaaaaaaaaaaaa... = 7; ) and they seemed to find that llGetFreeMemory decreased for sufficiently long variable names compared to shorter ones.  I wouldn't be surprised if constants also saved a byte or two, especially for strings and keys. OTOH, I vaguely recall reading somewhere that it used to be common practice (i.e for LSO scripts) to set key/string constants to (user defined) global variables if they were used a lot in the script. (i.e. gDEF_TEXT= TEXTURE_DEFAULT;)

Edited March 19, 2022 by Quistess Alpha

[Mollymews]

i don't know about the current Linden LSL compiler, but historically

the actual numerical value of a LSL constant label is output by the LSL CIL compiler

variable names (both local and global) tho are included in the compiled output. So shorter variable names do reduce the size of the compilation

 

some historical sources for looking into these things

https://wiki.secondlife.com/wiki/User:Becky_Pippen/LSL_Performance

https://github.com/Sei-Lisa/kwdb

https://github.com/Sei-Lisa/LSL-compiler

 

 

[Wulfie Reanimator]

18 hours ago, Arduenn Schwartzman said:

Hi all, does the use of constants yield a performance improvement over using their values? Like using ZERO_VECTOR is recommended over using <0.0,0.0,0.0>? Or is that a myth? I would have sworn I had read something about it somewhere on a Wiki, or in a forum.

Performance as in faster? Almost definitely not. Performance as in using less memory? Possibly, but it's hard to get definitive proof of what goes on since the compiler isn't available anymore.

18 hours ago, Coffee Pancake said:

Bytecode size is the only performance metric that counts for LSL.

Speed and responsiveness are subject to so many external factors as to make them irrelevant.

I would disagree with this, because I don't think less bytecode means faster execution (for that individual script, and it probably doesn't help overall sim performance either), unless you mean that scripters should only be concerned with memory consumption so the sim doesn't run out of memory, which I definitely disagree with.

And despite the speed/responsiveness having many factors that you can't control, you can still write the same script in ways that make the script significantly less responsive.

For example, instead of writing plain loops to compare/process lists, you'll benefit greatly from using built-in features like ListFindList because then all the slowness of LSL is offloaded to the optimized procedures of the simulator. The "loop" is guaranteed to complete magnitudes faster and it only gets better in lag. The same principle applies to any language/environment, whether that's Python or C (although compiled languages often get most of these optimizations automatically anyway).

Edited March 20, 2022 by Wulfie Reanimator

[Qie Niangao]

10 hours ago, Mollymews said:

the actual numerical value of a LSL constant label is output by the LSL CIL compiler

In order to do this, does the compiler deduce that a variable is actually a constant because no assignment nor increment/decrement operator is ever applied to it?

(FWIW, I'll echo @Wulfie Reanimator's position on speed vs memory size. Other than the overhead of a Mono script arriving in a new region, size rarely matters at all unless it increases the number of scripts and associated inter-script communications. Speed, on the other hand, can definitely affect performance—especially robustness to lag conditions.)

[Coffee Pancake]

4 hours ago, Wulfie Reanimator said:

I would disagree with this, because I don't think less bytecode means faster execution (for that individual script

On paper it might, in practice it's water under the bridge and not worth fussing about with, especially from our position so far removed from the interpreter. 

4 hours ago, Wulfie Reanimator said:

unless you mean that scripters should only be concerned with memory consumption so the sim doesn't run out of memory, which I definitely disagree with.

Overall script memory is not a concern, we must work under the assumption that the region hosts have lots, and should it ever become constrained (again) that is not an us problem.

OTOH Individual script memory is. An awareness of memory (and the profiling tools we have) means scripters can get a bit more bang for their buck when trying to keep things contained to a single script, avoid stack heaps on data intensive scripts that are in play for extended periods, and generally do better work that plays to the strengths of the system we have.

 

 

 

 

[Mollymews]

4 hours ago, Qie Niangao said:

In order to do this, does the compiler deduce that a variable is actually a constant because no assignment nor increment/decrement operator is ever applied to it?

i am just going off Becky Pippen's  x = PI; example snippet.  Sei Lisa's offering uses a look up table (KWDB) to fetch the absolute value of LSL constant labels, and given Becky's x = PI then I assume that Linden does the same

 

 

[Qie Niangao]

16 hours ago, Mollymews said:

i am just going off Becky Pippen's  x = PI; example snippet.  Sei Lisa's offering uses a look up table (KWDB) to fetch the absolute value of LSL constant labels, and given Becky's x = PI then I assume that Linden does the same

Oh duh! Of course, the real built-in constants, not the variables we define (without being able to declare const) on which I'd fixated.

Now I'm idly wondering if, in lieu of such const declarations, it could be worth a compiler's time to keep track of whether a variable is assigned a new value after declaration within scope, and if not make the same value substitution as for built-in constants. Save a bit of runtime.

[Mollymews]

2 hours ago, Qie Niangao said:

Now I'm idly wondering if, in lieu of such const declarations, it could be worth a compiler's time to keep track of whether a variable is assigned a new value after declaration within scope, and if not make the same value substitution as for built-in constants. Save a bit of runtime.

i wonder about this to.  I remember when Linden mentioned (quite a while ago now) that they were moving away from JIT to native byte code pre-compilations of CLR-ready assemblies.  Not sure how far down the road Linden got with this.  If Linden have gone all the way down this road then it would change things up quite a bit  (in how we might have a better understanding, in our efforts to write LSL code in an optimised way)

maybe one day Linden will add a Dump button to the code editor, which will dump the CLR-ready assembly code of the script to a local disk file. I would like this, as we be able to get a lot of definitive answers. Answers that we can only really guess at the moment

Edited March 21, 2022 by Mollymews
CLR

[Mollymews]

15 hours ago, Qie Niangao said:

 declare const

can we have this please Linden ^^

and can we have it in local scope as well as please!

Edited March 22, 2022 by Mollymews
and please

[Quistess Alpha]

5 minutes ago, Mollymews said:

can we have this please Linden ^^

can file a jira feature request. . . not that I'd expect much from it 🤷‍♀️

[Mollymews]

4 minutes ago, Quistess Alpha said:

can file a jira feature request. . . not that I'd expect much from it 🤷‍♀️

thats true

is just that Rider Linden and some Other Linden lurks this board. So is more of a hint really

and never know! Rider might go hmm! I could like that myself! And sorta slip into the job queue when Mojo Linden is feeling all content and happy after having a nice lunch

😺