Phil Deakins Posted March 10, 2018 Share Posted March 10, 2018 (edited) 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 Link to comment Share on other sites More sharing options...
Love Zhaoying Posted March 10, 2018 Share Posted March 10, 2018 It’s really just limited by memory available. Link to comment Share on other sites More sharing options...
Phil Deakins Posted March 10, 2018 Author Share Posted March 10, 2018 (edited) 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 Link to comment Share on other sites More sharing options...
Nova Convair Posted March 10, 2018 Share Posted March 10, 2018 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)); } } Link to comment Share on other sites More sharing options...
Love Zhaoying Posted March 10, 2018 Share Posted March 10, 2018 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.) 1 Link to comment Share on other sites More sharing options...
Love Zhaoying Posted March 10, 2018 Share Posted March 10, 2018 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. Link to comment Share on other sites More sharing options...
Nova Convair Posted March 10, 2018 Share Posted March 10, 2018 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)); } } 1 Link to comment Share on other sites More sharing options...
Love Zhaoying Posted March 10, 2018 Share Posted March 10, 2018 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. Link to comment Share on other sites More sharing options...
Love Zhaoying Posted March 10, 2018 Share Posted March 10, 2018 Test adding entries with a for() loop to see its only initialization that has a small max. Link to comment Share on other sites More sharing options...
Phil Deakins Posted March 10, 2018 Author Share Posted March 10, 2018 (edited) 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 Link to comment Share on other sites More sharing options...
Phil Deakins Posted March 10, 2018 Author Share Posted March 10, 2018 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. 1 Link to comment Share on other sites More sharing options...
Love Zhaoying Posted March 10, 2018 Share Posted March 10, 2018 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. Link to comment Share on other sites More sharing options...
Sasha Ferd Posted June 7, 2020 Share Posted June 7, 2020 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. Link to comment Share on other sites More sharing options...
Recommended Posts
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