llSetMemoryLimit

[ChinRey]

I've noticed no scripts posted on this forum use the llSetMemoryLimit function. Is it redunant?

[Rolig Loon]

Search the SLU forum for a discussion last January. I'd post a link, but that's not allowed.

[arton Rotaru]

For me It's main purpose is to appear with lower numbers on those Avatar boards which show script memory and such. :matte-motes-confused:

Technically it's more or less redunant, because it just limits the maximum number a script will be able to allocate until it crashes.

A  Mono script will have only as much memory allocated as it needs, not the 64 KB it always returns by default.

However, I use it for said reason on my products.....

 

 

[ChinRey]

Thanks!

This should have been clarified in the wiki - I've herd even experienced scripters talk about reducing memory use with the llSetMemoryLimit. Unfortuantely only a few selected Lindens are allowed to edit the wiki these days so there's nothing we can do.

[Rolig Loon]

The wiki software is being replaced with a new version.  Until then, it's uneditable.  The word on the street is that it won't be long, but I don't know how long "long" is.

[Miranda Umino]

Give up this function .

It s totally and completely useless

 

Your "experienced scripters" are only noobs

[Nova Convair]

This function has no advantage - it is completely useless.

If you want to please the meter-using-fools you can set the memory to maximum at the beginning of each event. At the end of each event you set it to the minimum.
That has absolutely no effect on the script or memory usage of course so it's useless. But the script meters will show low memory most of the time.

Well I don't do that. I ignore meters, so I don't need this function at all.

[Qie Niangao]

The function does serve a purpose, just not the one folks expect it to serve, nor the one for which it was originally designed.

It causes a script to crash if it dynamically allocates more memory than the function allots.

That's not usually what you want, and I don't think I've ever used it for this, but it's easy to imagine an application where, very rarely, a system call generates an unmanageably huge return value that the script shouldn't even try to process, and because that's so rare, it's more efficient for the script to terminate with an out-of-memory error (and the system to recover from the crashed script) compared to testing memory usage the 99.999% of the time it succeeds.

(What it was originally designed to do, of course, was to enable scripters to fit scripts to parcel- and avatar-based memory constraints that ended up never being imposed.)