Jump to content

Disadvantages with long variable/function names and comments? (solved)


Kaya Kiyori
 Share

You are about to reply to a thread that has been inactive for 3391 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

Greetings,

I want to know if long variable/function names or long comments have any disadvantages for the script, that we wrote. (disadvantage for performance or memory)

At the beginning I tryed to write with short variable, function names and made the comments to a minimum, because I thought this could be produce a bad impact to the script. But since Mono, I'm not sure.

Now... some years later, in other script-languages I working with long self explainig names and comments. But there it isn't really a problem, because these script-languages allowing clean and minfiy possibilitys.

Hope anyone can share his/her experience about that.

Link to comment
Share on other sites

Two that I can think of:-

  1. Script filesize/bit-length matters, longer variable names/comments = more space needed to store the script source. (my understanding is that comments don't 'lag' while processing, but since they're stored somewhere it'll inflate disk size at some point)
  2. Easier to mis-type, more characters = more potential for typing errors when typing out variable names.
Link to comment
Share on other sites

The more LSL scrtipting I do, the longer my variable names tend to get. I, too, started out using short names but I quickly learned that it's easier to keep track of variable types and uses if I put more information into names. Now, I tend to write variables like giNumberOfAvatars to remind me that I'm working with a global integer that counts how many avatars are around, instead of using something generic like num, which I'll only use as a throwaway.  There's a small loss in memory useage when you use longer names, but the gain in information beats that disadvantage.

Link to comment
Share on other sites

I think no disadvantages
The compiler generates a code for the virtual machine and that code need no comments nor variable names
It works with or without a source code
It can be copied and transferred as a working script without a source code

So a script is not just a script, it has a source code and a machine code which can be separated and live separate lives

The source code is visible and readable in an editor, the forum, the wiki etc. but can not act with the SIM server
The machine code can act with a server even after the source code is lost

:smileysurprised::):smileyvery-happy:

  • Like 1
Link to comment
Share on other sites

it depends on how LL have implemented/optimised the LSL to IL code and then how optimised is the IL assembly/compilation to machine (runtime) code

have never seen any IL code that LL LSL produce so dunno exactly. But can assume that is pretty well optimsed so that identifiers (function and variable names) have a minscule bearing on compilation time

+

also I think that LL use pre-compiled assemblies of scripts (NGEN) as much as possible minimising the use of JIT compilation. Which further lessens any impact that identifiers might have

i think this is true of LL bc I remember reading one time (dunno where exactly now I read it) LL saying that when using a script (that does the exact same thing) in multiple objects on same sim server then compile the LSL script once. Copy it to Inventory and then copy it back to each object. This means the same assembly will be used for all

if recompile them seperately then a new assembly for each will be created, adding unnecessary load to the server

+

so after all that (:

if it makes sense to you to use longer names (for code clarity purposes) then do it. bc any performance benefit you might hope to get from using short names may be non-existent anyways

 edit: tpyo

Link to comment
Share on other sites

Hi Sarah,

As the others have stated, variable name length and comments have no effect on the execution of a script. The human readable script is translated (compiled) into either the native numeric instruction codes for the underlying computer (machine code) or some intermediate form that is independent of the underlying computer (a sort of virtual machine code that is then interpreted by a program running natively on the underlying computer). I don't know which method is used by Mono in SL, but it doesn't really make much difference.

Variable  and function names are replaced with memory addresses, which are all the same size (32 or 64 bits these days). Comments are discarded altogether. The source code does take space on the servers, but I doubt that's loaded into memory when the script executes. It's simply saved in the script file on disk somewhere in the system, so you can edit and recompile it. Only the result of the compilation should be loaded into server script memory.

And, even if that were not the case and the designers of the system were silly enough to load source code that's never touched, it would still be small in comparison to other side effects of running scripts. The entire text of War and Peace is about two megabytes. A typical script of mine is perhaps a kilobyte or two. All I'd have to do is declare a list with a few hundred elements and I'd consume more memory than the source of any script I've ever written.

If the LSL scripting system doesn't provide re-entrant functions (functions that can be simultaneously called by multiple scripts at the same time, and therefore shared), then every script that calls a function will force a copy of that function's code to be loaded along with the script. I could imagine the entire LSL function library taking tens of megabytes, and that you could call every function in it using a script that's less than 10 Kilobytes of source text.

The reason we name things, whether in a script or in our real lives, is to make life easier to understand and to avoid mistakes. Those are your concerns.

Have fun!

 

  • Like 1
Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 3391 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...