lsl Function or variable?

[Vick Forcella]

What is best to use and why?

A function like llGetOwner() used 30 times in a script or string owner = (string)llGetOwner() and use the variable 30 times. What is faster, what uses the least memory?

[Qie Niangao]

The latter will win for speed and memory size--especially if you really mean (as shown) that you want it expressed as a string instead of a key.  Typecasts take some processing, too.

I'm assuming here that the alternative is to have llGetOwner() actually appear 30 times in the script, which is different from that function merely being executed 30 times from a single place in the script, as in a looped block.  If the latter, I think you could save a tiny amount of memory by just invoking the function each time instead of referencing a stored variable, but at a cost in processing time for all those function calls.

(You can test this yourself, you know, if you really want quantitative results.  They'll be more dramatic for LSO than Mono, and could even differ in direction--although in this case, I doubt it.)

[Meade Paravane]

Personally, I would use llGetOwner() becuase it's something that can change and is something that is very, very easy for the sim to get at.

It might be a little more expensive in terms of CPU usage but a script that works and is a tiny bit more expensive is better than one that doesn't work because you forgot to reset on owner change.

OTOH, if you're talking about a tight loop that needs to access the owner ID, I'd have a local variable outside the loop and assign that to the owner ID then use the variable in the loop.

[Ansariel Hiller]

Executing the function once and storing its return value into a variable should be the better solution. After the first call of the function you only need to access the value stored at the memory location of the variable. By the time you have invoked the method you already will have the value from the variable, and then you still would need to wait for the function to retrieve the value itself.

[Void Singer]

while storing the variable is helpful space and speed wise, it may not be useful in all paradigms... it will require that you detect changes to the owner and reset the script each time a new owner is detected.... this can be tedius in multi state scripts. however if you do things like listen for the owner, then it's not going to hurt since you needed a reset to deal with that anyway (because it would listen to the old owner otherwise).....

overall I wouldn't use a variable unless it replaces at least 3 constants or calls to that particular function, unless for some reason you're using it in a long loop, in which case I'd think you should look at THAT problem first.

---

[Meade Paravane]

Executing the function once and storing its return value into a variable should be the better solution. After the first call of the function you only need to access the value stored at the memory location of the variable. By the time you have invoked the method you already will have the value from the variable, and then you still would need to wait for the function to retrieve the value itself.

I don't know what it costs to set up a function call in the innards of LSL but the owner key is something that the sim knows off the top of it's head. I can't imagine that its much faster to access a script variable than it is to do a function call and get at a C++ variable.

If the OP is down to this sort of thing to make their script speedy, they're doing pretty damn good.

[Qie Niangao]

That's a good point about the owner changing.  This is a common reason for the on_rez / reset cliche, although that's often clumsy overkill, when what's really needed is a response to the CHANGED_OWNER event.  Or, when performance isn't essential, just eating the overhead of an extra call to llGetOwner(), as you suggest.

[Ansariel Hiller]

Invoking a method is always more cost intensive than reading the value of a variable from memory, especially since in this case it is a value type variable. Beside this, we don't know if the owner key is already available inside the LSL environment or if the call has to be marshalled to the sim.

[Meade Paravane]

Invoking a method is always more cost intensive than reading the value of a variable from memory

 

I think I said that too.

The difference is that I think it's a trivial amount of extra work. Extra work? Ok. Lots of extra work? Nope - I don't think so.

[Ansariel Hiller]

Uhem true... maybe I better get some glasses...

[MJake Darkfold]

    While I can't comment knowledgeably regarding relative 'efficiency' (time / memory) - I would like to offer my more 'style-related' opinions (even if they might be partially just reiterating comments made above).

    Personally - since even before "OOP paradigms" and associated techniques such became all the buzz (yeah, I've been coding that long >g<), I've leaned strongly towards getxxx() / setxxx() functions / methods / &c.; this is largely due to the priority I place on 'maintainability', ergo *my* resources (time / effort / &c.) are generally more valuable than those on any machine.  Using functions / methods make it much easier (as mentioned previously) to adapt your code when you realize at a later date you need it to do something more / different (and really, who amongst us can honestly say they've forseen *every* future need of a piece of code ?).  Also - makes it *much* easier to find / identify / distinguish 'read' vs. 'write' access to various items.  I just feel it's "good style" all-round.

    Further - though there *are* occasions that it becomes necessary to "get down to the metal" and tweak code with the utmost attention to such details - in my experience, most things that are suited for coding in a scripted language do not fall in such categories, and 'maintainability' is a much greater concern.  Also, in the vast majority of coding of any sort - considering different algorithms usually brings a greater "yield" than other techniques.

    While a bit tangential - hope you find this useful !

    Be well & enjoy -

        - Jake