Jump to content

Variables vs lists efficiency


Rhiannon Arkin
 Share

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

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

Recommended Posts

19 minutes ago, Rhiannon Arkin said:

Hi

I was wondering how to measure speed and efficiency in more complex scripts. 

I am mostly curious about the usage of many individual variables vs lists. Is there empirical data available which of the two is more efficient ? speed and memory wise. 

curios..

Variables and lists are two entirelly different things. Variables can be global or local. Lists can be global or local. Variables are limited, lists are for more advance data storage. As for speed and efficiency that depends on how you use variables and lists. Memory wise scripts are allocated 64k unless script capped. Put it this way you do not use a list when you can assign a variable.

Edited by steph Arnott
Link to comment
Share on other sites

2 hours ago, Rhiannon Arkin said:

Hi

I was wondering how to measure speed and efficiency in more complex scripts. 

I am mostly curious about the usage of many individual variables vs lists. Is there empirical data available which of the two is more efficient ? speed and memory wise. 

curios..

It depends. If you are only wanting to store one or two things then individual variables would probably better suit your needs. If you want to store bigger amounts of data then lists would probably suit your needs. You can think of a list as a container for either one or multiple types of data.

 

As for speed. There are a few ways you can check but the most basic one would be using llGetTime();

So for example

float timeStart=llGetTime();
llOwnerSay("i am a function");
llOwnerSay("i am another function);
float timeEnd=llGetTime();
float finalTime=timeEnd-timeStart;

Then run it several times and take an average of the results. There are other ways to do this but I'm giving you the most basic as I am not sure of your skill level at coding and I don't want to overload you

 

Memory of variables vs lists. Well again that depends on how much data is to be stored in the list. Sometimes variables take up less space, sometimes a list takes up less space. But a basic way to check is using llGetFreeMemory(); which will tell you how much memory is used in the script out of the 64000kb limit. 

Link to comment
Share on other sites

In a very general sense, variables will always be faster and use less memory than a list. This is because a list has some additional overhead required for storing and keeping track of the things in that list.

A variable is a direct reference to a value, you don't really get much faster than that.

When you have a list with more than one value, you must use one of the llList2* functions to access specific values. This is already less speed efficient, but it also takes more memory in bytecode because of the two parameters and return value.

Lists get more efficient the bigger they get though. A list with 1 value contains as much overhead for storing it as a list with 10000 values, but lists will never be as efficient as a direct variable.

But if you ever have to search a list for a value, speed efficiency tanks almost always. However, you can't use multiple individual variables for this purpose, so it is your only option sometimes.

With all of this said, you really shouldn't worry about the "efficiency" of variable vs list. The difference rarely makes... a difference... and you should focus instead on code that makes sense. Worry about efficiency only after you find a real problem. 

Edited by Wulfie Reanimator
  • Like 4
Link to comment
Share on other sites

In addition to what's already be said, if you are interested in making measurements of the speed and memory usage of variables vs lists, there are a few wiki pages that can aid you.

http://wiki.secondlife.com/wiki/LSL_Script_Efficiency
This page has a section that provides a sample script which you can use to measure how fast a snippet of code runs. Ideally, you should only attempt this in an otherwise empty sim with no other people nor scripted objects (rezzed or attached) in it. An isolated sim with no connected regions would be best - to minimize the possibility of objects/avatars waltzing in. Also ensure your avatar is seated, so as to avoid the simulator spending resources to process any movement.

http://wiki.secondlife.com/wiki/LSL_Script_Memory
This page lists the results of testing done by others in an attempt to measure how much memory is consumed by various actions, including variable usage. Though by the page's own admission, the accuracy of those measurements are not absolute, so take them with a grain of salt.

For memory measuring, you would want to look into the function llGetUsedMemory before and after using the bit of code you wish to measure. Another option is llScriptProfiler, though that focuses on the overall script's memory usage during the profiling session.

Edited by Fenix Eldritch
  • Like 3
Link to comment
Share on other sites

10 minutes ago, Rhiannon Arkin said:

Thanks that's all helpful. 

Is it then correct to assume that clearing a list actually frees up memory during operation? 

There are two types of lists. Semi-permanent and temporary. Semi-permanent  are used when that data needs to be kept and re-used. Temporary are for a code blocks that need data held for a local operation. Clearing a semi-permanent list with data that will have to be re-populated uses more memory at the time of re-population. Clearing that list for no valid reason is pointless.  Deleting a value in that list that is no longer needed is the usual action.  Sorting lists into a logical order uses less memory when data is searched for and an operation jump out is used. When lists are searched or updated etc a temp copy is made for camparison purposes. That temp allocated memory has no effect on the scripts allocated memory.

To be clear lists are a minor memory issue if correctly managed. Nearly all memory issues are caused by poor code structure. Using user created functions for two lines of code which  are allocated 512bytes is a common example of gross memory wastage. Not sorting if conditionals in to releivent blocks or a pile of if conditionals that should be else if conditionals is another. ETC. Concentrate on efficient scripts first before worrying about list contents. If you are filling a list with junk then you are not managing the lists very well at all.

 

  • Like 1
Link to comment
Share on other sites

2 hours ago, Rhiannon Arkin said:

Is it then correct to assume that clearing a list actually frees up memory during operation? 

Pretty much. The memory consumed by a script can be divided into two general categories. You have the area of memory that stores the compiled bytecode of the script - colloquially called the "heap". It is static and does not normally change unless you recompile the code. The other area is used for scratch work, storing variable contents, saving pointers when functions are called, etc - colloquially called the "stack". This area is dynamic and can grow and shrink during runtime. Both the stack and heap must co-exist in the chunk of memory allocated to the script, by staying in their respective corners. If the stack gets too big, the script crashes. This kind of error is called a "stack-heap collision" because the stack literally grew so big, it spilled over into the area that was supposed to be reserved for the heap.

As an example, if you have a script that stores the name of nearby avatars into a list, that list can potentially keep growing. If left unchecked (and coded in such a way that you keep adding to the same list), it will eventually consume all the memory allocated to the script and crash. Lists aren't the only way this can happen too. Similar scenarios can befall strings, and even scripts that get stuck in infinite recursive function call loop and never bottom out.

Edited by Fenix Eldritch
typos
  • Like 1
Link to comment
Share on other sites

1 hour ago, Rhiannon Arkin said:

 

I tried to find a simple example of rapid variable updating using a temp list. This is a good example.

//Basic Owner Follower by Ugleh Ulrik
default
{
	state_entry()
	{
		llSetTimerEvent(0.1);
	}
	timer()
	{
		vector OFFSET = <1.0,1.0,0.0>;
		vector OwnerPos = llList2Vector(llGetObjectDetails(llGetOwner(), [OBJECT_POS]),0) + OFFSET;
		//Comment one of the below functions based on what you want.

		//llMoveToTarget(OwnerPos,0.05);
		//Use llMoveToTarget for Physical Objects.

		llSetLinkPrimitiveParamsFast(LINK_THIS,[PRIM_POSITION, OwnerPos]);
		//Use llSetLinkPrimitiveParamsFast for Non-Physical Objects.
	}
}

 

Edited by steph Arnott
Link to comment
Share on other sites

On 3/14/2019 at 12:35 PM, Nova Convair said:

How efficient and memory consuming might be the if / else construct for 100 variables?

The question of the OP is irrelevant. :)

 

Right!  Or readability?  How much of a nightmare will the code be to fix with more than a few if...else statements as opposed to two lists and llListFindList?

The biggest advantage with llListFindList over multiple if...else statements or a loop counter, the statement simply evaluates the list for the string or variable you're looking for, and returns a value telling the script where that item is in the list, or telling the script to stop looking.  I have a feeling that the time and resources used with a single line finding something in a list makes up for the time it takes the script to evaluate multiple conditionals.  I may be mistaken, but it certainly makes up for the time I need to debug a script.

I've seen "Lucky Letter" style scripts where it's all if...else statements instead of using one list to set a pointer to another list that contains the texture offsets/repeats for 28 to 37 different vectors on a single texture.  (At least I hope it's a single texture and not somewhere between 30 or 40)

Edited by RozWright
  • Like 1
Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 1528 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...