New Citizens Inc

As vague as it seems, what they're pretty much saying is that 1 compile + 1 sim = 1 bytecode for all duplicates. But, if you compile again, it's pulled from the bucket into its own space. (^_^)

So, distribute 30 night/day scripted lamps from inventory and/or shift-copy, and they'll all run on their own threads based on the same asset of byte code. This does not mean they're sharing memory allocation, though. Now, if you were to go to each lamp and recompile the script, one-by-one... Suddenly you'll have 30 separate instances of the scripts, all with different asset IDs. (>_<)

So, optimally, when editing and/or re-compiling... You'd want to do ~that~ once and re-distribute the script instead of going copypasta across the board. (^_^)y

OK, got it. And it's just the bytecode that's shared, of course. Still perhaps worth doing ... thanks!

I have heard that the bytecode sharing has most likely gone to the same sewer as dynamic memory allocation in Mono, but Lindens havnt said anything specific about it, and only ppl who have access to the actual server computers can assess that.

fr43k Paine wrote:

Beverly Montgomery wrote:...and fr43k didn't you know that some scripts still work even after being removed. hehehe just a reminder there.

I did know that, Bev. One question was, if we could use that to our advantage.

Scripts won't run after they are removed, there's no magic in SL

There are some prim properties that are set by a script, and once set the properties stay even after the script is removed, such as hover text, color, particle system, texture animation,... and some of them may look like as if the script is still working, while they are actually done by the client, not by the script.

Also worth keeping an eye on what happens with Mono2 which isn't far away. http://wiki.secondlife.com/wiki/Mono2

anybody tried the new script memory reporting being tested on Le Tigrre servers?
http://wiki.secondlife.com/wiki/Beta/LeTigre

New Script Profiling LSL Functions

* llScriptProfiler can enable or disable memory profiling with PROFILE_SCRIPT_MEMORY and PROFILE_SCRIPT_NONE. While profiling the scripts performance will be severely impacted.
* llGetSPMaxMemory will report the highest level of used memory during the most recent, or current, profiling run.
* llGetUsedMemory will report the current used memory of the script and does not require profiling to be enabled.

I haven't. My own sim is on the Magnum channel. (._.)

Looks promising, though. It'd be fun to add those stats to a lag monitor. (^_^)

Kuula's on Le Tigre

The big change in memory is the llSetMemoryLimit function, which only works in Mono scripts
LSL scripts automatically used 16k of RAM, while Mono uses 64k, so it paid to compile small scripts as LSL.

With the new function, a small script in Mono can be set to use less than 16k of RAM. And since most of the problems arising from using Mono scripts have been fixed, the potential gain is significant.

WolfBaginski Bearsfoot wrote:The big change in memory is the llSetMemoryLimit function, which only works in Mono scripts
LSL scripts automatically used 16k of RAM, while Mono uses 64k, so it paid to compile small scripts as LSL.

With the new function, a small script in Mono can be set to use less than 16k of RAM. And since most of the problems arising from using Mono scripts have been fixed, the potential gain is significant.

Hmm, I haven't checked now, but I thought LSL scripts would always use 16k, and Mono scripts would use only what they need, limited to 64k. If that were true, a Mono script can limit that maximum now using llSetMemoryLimit. It would also be a better explanation of the function name.