Can we talk about increasing Script memory from 64kb ?

[Quistess Alpha]

21 minutes ago, Mollymews said:

we can test for the presence of a key with  llReadKeyValue  http://wiki.secondlife.com/wiki/LlReadKeyValue

if the key doesn't exist then it returns an error

I know, I have read over what it can do, Yes you can check if "MyApplication:"+key; is a valid key in the database, you can't ask what keys are in the database without using llKeysKeyValue, which can't filter.

[Mollymews]

47 minutes ago, Quistess Alpha said:

I know, I have read over what it can do, Yes you can check if "MyApplication:"+key; is a valid key in the database, you can't ask what keys are in the database without using llKeysKeyValue, which can't filter.

when we want more than one app to access the same domain then we stick the key names in the value of a domain meta record. Example:

string DOMAIN = "MyApplication:";

llCreateKeyValue(DOMAIN + "Meta.Keys", llDumpList2String(keys, "|"));  // or llUpdateKeyValue as we prefer

other app can then query: DOMAIN + "Meta.Keys"

 

KVP is pretty basic and could do with more love for sure tho

 

 

[Mr Amore]

Back when I timed the response from a database at the same AWS location, it was within 0.2ms.

 

The improvements I'd like to see for the Experience store:

•  Accessible anywhere
• Increased KvP limit from 4k
• Option to store data as a list type, and to act upon it directly with llList style functions

The SL Experience,  KvP store and implementation of JSON are popular hate topics, I'm in the few who appreciates them. But the data limits are crippling, in scripts and in KvP transactions too.

 

A few years back, I did an urban sim's communication system where characters could leave messages for one another. Characters also had a criminal record(viewable by law enforcement), and medical records(viewable by clinic staff). Then to communicate, there was a character directory to find the individual you wanted to message.

I spent more time scrapping, redesigning and refining the data structure than actually coding, with every KvP byte accounted for. In this instance, the script created multiple KvPs for every character joining the sim.

Using the Experience store could be so much simpler if we could search, or extract xx elements at a time, or just use the store as a 128MB extension of the LSL list.

[Apollosmile]

Because it will enable me to import this absolute masterpiece! That's only possible in opensim because it has more memory 

 

[Frionil Fang]

Even if this is thread necromancy, 64 k and a single script are enough for multi-channel music playback, thanks to being able to set up and offload stuff via linkset data. You're more likely to run into the sound throttle (max 22 sounds per second per object) before memory limits IMO, and running multiple scripts and objects would cause more latency problems - and if your track is so complicated it requires more sounds than that, then you'd be using multiple scripts and would have more memory at your disposal anyway. Starts at 2:42 in the video if the timecode didn't copy over to the URL.

yes it's a shameless plug

[Love Zhaoying]

With Linkset Data - you get 128kb extra memory storage (stored in the Object the script runs in)..

Since Linkset Data was introduced, I have almost no memory issues with scripts, because I write my scripts to use Linkset Data LSL Functions.

 

[Alwin Alcott]

8 hours ago, Apollosmile said:

 to import this absolute masterpiece!

 De gustibus non disputandum est.

[Quistess Alpha]

synchronizing multiple short sounds for a midi-like music synthesis in SL works ok when the stars align and lag is low, and granted the last time I played with the idea was before the big script efficiency update, but when it goes badly, it goes really badly. I don't think it would work well in a region with any sizeable number of people in it.

[Frionil Fang]

21 minutes ago, Quistess Alpha said:

don't think it would work well in a region with any sizeable number of people in it.

Depends, I tested the song from the video I posted on a sim with 0 ms spare time and 48 people, it's a little sloppy but not unbearably so, I'd say it stays in sync as well as the big fancy thing from the other clip. The test song doesn't push the tick rate to its maximum, but the sound rate throttle makes such tick rates impossible to get much use of unless you're just playing single-channel. On an unburdened sim it stays in near perfect sync nearly every time. The script efficiency changes made stuff like this a ton more tolerable.

Mine has only 4 channels though, 1 script, 8 kB song memory, which is enough for a couple minutes.

Edited November 7, 2023 by Frionil Fang

[Apollosmile]

It has been tested and I have held multiple concerts full of people and it did not lag a single bit  The Crescent Melody is optimized to handle up to 40 users. https://hgsafari.blogspot.com/2023/02/crescent-roll.html

[Kristy Aurelia]

On 9/13/2021 at 11:39 PM, animats said:

I'd like to have the stack memory counted separately from code and heap

This is probably the best long-term solution. Splitting code from memory would allow optimizations such as: when an avatar object comes close to a region crossing, the neighbouring sim could preload script code data over multiple seconds ahead of the avatar crossing the border, and on border crossing, it would only need to load in the actual memory part. If the avatar moves away, it could discard the code data at a convenient time.

It would also help with silly things like global variable and function names eating up script memory.

And it would give more flexibility for extensions in the future, such as increasing code memory, but not heap, or heap memory but not code etc.

Code being separate also has an advantage that it would only change if a script is saved.

[animats]

5 hours ago, Kplh said:

This is probably the best long-term solution. Splitting code from memory

That's something different - stateless scripts. Ones where a script reset when the script is idle is harmless. There aren't that many stateless scripts. Most scripts that seldom run have state. They know your shoe size, in the unlikely event you suddenly need to resize your shoes. There are hundreds of thousands, maybe millions, of chairs in SL waiting to be sat upon, and their sit scripts have state. It won't help for the biggest causes of idle scripts that take up space.

I was asking only for protection against an incoming event blowing the stack before the script had a chance to check the length of the incoming item and reject it. That's a specific problem for systems of scripts with lots of internal link messages.  A link message goes to all the scripts in a prim, whether that script needs it or not. That adds overhead. There's no filter for link messages and if the str value is too big, the script crashes.

A simpler fix would be for LSL to have an optional filter for link messages. You'd give a list of the id values you want to see, and link messages with other IDs are ignored. This is useful for complicated systems of interacting scripts, where script to script messages need better routing control. It's not a general problem, though.

64 bit simulators are coming, apparently. The SL simulators are all still 32-bit programs running on Linux. This is kind of dated. That will permit more memory per simulator.

[Kristy Aurelia]

20 minutes ago, animats said:

That's something different - stateless scripts. Ones where a script reset when the script is idle is harmless. There aren't that many stateless scripts. Most scripts that seldom run have state. They know your shoe size, in the unlikely event you suddenly need to resize your shoes. There are hundreds of thousands, maybe millions, of chairs in SL waiting to be sat upon, and their sit scripts have state. It won't help for the biggest causes of idle scripts that take up space.

I was asking only for protection against an incoming event blowing the stack before the script had a chance to check the length of the incoming item and reject it. That's a specific problem for systems of scripts with lots of internal link messages.  A link message goes to all the scripts in a prim, whether that script needs it or not. That adds overhead. There's no filter for link messages and if the str value is too big, the script crashes.

A simpler fix would be for LSL to have an optional filter for link messages. You'd give a list of the id values you want to see, and link messages with other IDs are ignored. This is useful for complicated systems of interacting scripts, where script to script messages need better routing control. It's not a general problem, though.

64 bit simulators are coming, apparently. The SL simulators are all still 32-bit programs running on Linux. This is kind of dated. That will permit more memory per simulator.

'stateless scripts' - uhm, not really what I meant, I mean a script is like an exe, it uses no memory on the heap/stack until it runs. If the script code and stack/heap was separated. those could be move around separately. If you save the exe and memory separately, you could move exe around as you please, and then load in and let it work with a chunk of memory. Effectivery what hybernation does.

But at the moment, the same memory budget is used by the entire script, including code, stack, event queue. global varaibles. And the code could be separated from that as it is static. Having separately controlled budgets for all of them would give the system the most flexibility.

 

On a different topic: 32bit sim does sound stupid, you could go on a 30k prim sim, rezz 30k boxes and fill in ~3.7GB of LinkSetData. Edit: especially when you consider dropping 32bit viewer... which is used by large group of people on video variety of machines... while a sim is in a closed and controlled environment... Why wasn't the server updated to 64bit way before the viewer? Surely it is easier when there are no customers with outdated PCs to worry about.

Edited November 18, 2023 by Kplh

[primerib1]

On 11/19/2023 at 1:45 AM, Kplh said:

you save the exe and memory separately, you could move exe around as you please, and then load in and let it work with a chunk of memory.

In a way, that's already implemented in Mono.

"Executables" coming from the same script gets loaded only once and its state are rotated per instance. It's called "bytecode sharing".

[Bleuhazenfurfle]

On 11/28/2023 at 10:36 PM, primerib1 said:

In a way, that's already implemented in Mono.

"Executables" coming from the same script gets loaded only once and its state are rotated per instance. It's called "bytecode sharing".

Which makes it rather cheeky that every single instance of the script counts the size of the bytecode out of it's memory allowance…  Gotta love cloud economics.

Though, just imagine how much of a mess it'd be if it didn't…!  Maybe we should ask for bytecode-pooling rebates that we can apply to future scripts?