List: max number of items

[Phil Deakins]

Way back when (pre-Mono), there was a maximum number of items that a list could contain. If I remember correctly, the way round it was to create more than one list and add one to the other. Does a maximum number of items still exist? If so, what's the maximum?

I have reason to think there's a still a maximum, and I think it's 75, but I just want to check.

Edited March 10, 2018 by Phil Deakins

[Love Zhaoying]

It’s really just limited by memory available.

[Phil Deakins]

No, it's not memory, Love. I have plenty of that left, and I can't add an item beyond 75.

Come to think of it, the 75th item was truncated. But there's plenty of memory left. I'll do an experiment or two.

Edited March 10, 2018 by Phil Deakins

[Nova Convair]

The number of list elements is not limited but by available memory. What Phil means is: how many elements you can assign in the script header.

Example:

list data = [1,2,3,4, ... ,75];

In the past there was a limit. I don't know if the limit still exists since I don't need that large initializations in my scripts

But try it out - just add more elements for data:

list data = [1,2,3];

default
	state_entry() {
		llOwnerSay((string)llGetListLength(data));
	}
}

 

[Love Zhaoying]

So, try this: if it were a list of very small strings (1 character) vs. integers vs. keys, they should all hold different max list count. Make sure your test code for this purpose has nothing else but setting a list - if you have a bunch of code, you’re just being fooled due to not much memory available.

Code tricks used to “help” under Mono with list management to do memory cleanup / garbage collection but those tricks aren’t necessarily helpful anymore due to better GC under Mono such as: list1 = [] + list1+ [newitem].

  The problem being, depending on how you manage your list, it requires you to have at least the current list size memory free in order to add an element because it makes a copy of the list.

  The craziest thing I’ve seen lately is a case where script memory seemed artificially low - and was not fixable by reset/recompile until I copied the code to a new script, then I got a lot of memory back.

  (In Trump voice) Believe me, I’ve got a lot of time in scripts/memory (except I’m not lying like when Trump says it.)

[Love Zhaoying]

6 minutes ago, Nova Convair said:

The number of list elements is not limited but by available memory. What Phil means is: how many elements you can assign in the script header.

Example:

list data = [1,2,3,4, ... ,75];

In the past there was a limit. I don't know if the limit still exists since I don't need that large initializations in my scripts

But try it out - just add more elements for data:

list data = [1,2,3];

default
	state_entry() {
		llOwnerSay((string)llGetListLength(data));
	}
}

 

Interesting, if only he had said that lol! 

Solution, initialize your list a different way.

[Nova Convair]

Circumventing this is easy

list data = [1,2,3, ... 75];

default
	state_entry() {
		data += [76,77,78, ... 150];
		data += [151,152];
		llOwnerSay((string)llGetListLength(data));
	}
}

 

[Love Zhaoying]

2 minutes ago, Nova Convair said:

Circumventing this is easy

list data = [1,2,3, ... 75];

default
	state_entry() {
		data += [76,77,78, ... 150];
		data += [151,152];
		llOwnerSay((string)llGetListLength(data));
	}
}

 

Yep or set the whole thing in code. 

You’d be amazed at some optimizations, the most depressing I found is that it takes 256/512 bytes overhead for every 1-2 functions, so for memory thirsty scripts I’ve saved upwards of 22k rolling multiple functions together.

[Love Zhaoying]

Test adding entries with a for() loop to see its only initialization that has a small max. 

[Phil Deakins]

Actually, I don't mean in the declaration, Nova. It's a list that starts with nothing in it, and is added to at runtime.

I've done a bit of experimenting, and it has the appearance of being memory, because I can add many more items to the list than the 75 I mentioned earlier, provided that they are smaller items. The items are avatar names - more short names can be added than longer ones, and yet it doesn't seem to make sense. Here's the situation...

The script runs in mono.

When adding avatar names to the list only around 75ish can be added before the last one is trucated and fails. No more can be added after that.

The free memory at that point is ~9k.

The memory used is 56518b, which is about right.

No stack-heap collision occurs.

It raises a different question. Assuming that the stack is included in the memory used figure, which will be why there is no stack-heap collision, there is plenty of memory available, so why is the last one truncated and no more items can be added?

 

Edited March 10, 2018 by Phil Deakins

[Phil Deakins]

Alright. I'll be logged into SL for the next few hours whilst anyone who wants to can send me IMs stating that I am an idiot. You can even tell me how much of an idiot I am.

It wasn't the list item that was being being truncated. It was the text in llOwnerSay(text) that was truncated. I wasn't showing the number of items in the list - I was printing them out in local - and the maximum number of characters for the local chat didn't occur to me until a few minutes ago.

So you were right - it's limited only by memory. Thank you.

[Love Zhaoying]

14 minutes ago, Phil Deakins said:

Alright. I'll be logged into SL for the next few hours whilst anyone who wants to can send me IMs stating that I am an idiot. You can even tell me how much of an idiot I am.

It wasn't the list item that was being being truncated. It was the text in llOwnerSay(text) that was truncated. I wasn't showing the number of items in the list - I was printing them out in local - and the maximum number of characters for the local chat didn't occur to me until a few minutes ago.

So you were right - it's limited only by memory. Thank you.

Yup with your scenario, you should have gotten stack-heap errors.

[Sasha Ferd]

Hi, I'm not really a high level coder, but I threw this together and stuck it in a cube I rezzed.

default
{
    state_entry()
    {
        list test;
        integer count;
        for(count=0; count<=llPow(2,20); count++)
        {
            test+=count;
            llOwnerSay((string)llGetListLength(test));    
        }
    }
}

I got stack heap collision at 3846 on mono, and 472 without mono. Dunno if anyone's interested in this thread or if this is helpful at this point.