[opensource-dev] 2.0 Absolute Dealbreaker - script count feature request

Kelly Linden kelly at lindenlab.com
Wed Sep 29 16:06:46 PDT 2010

* In the end the number of scripts shouldn't be important. I have lofty
desires to remove the arbitrary limit on script size so that we can stop the
silly games of splitting scripts apart because you need 10k more memory than
the default. On the other side being able to declare that your script really
only needs 4k would be hugely beneficial. At that point reporting the
reserved memory is more meaningful than the number of scripts.

* Script memory *is* very important, but it isn't counted in ms.

* Script ms is a wonky stat and I'm loath to perpetuate it. It only has a
rough correlation to actually harmful scripts. When scripts are behaving we
do a really great job of only giving each one a small slice of time, not
effecting the simulator, and giving everything a chance to run. When we run
into problems is when specific functions are called, which is something you
allude to. A great example is object rez. These function calls need to be
fixed on a case by case basis so that they aren't a problem. Object rez is a
great example here too - there are actually quite a few improvements in the
pipe to make it suck much less.

Script ms will show these horrible offenders because we do count that time
against the script. However the script ms time is really only good at
identifying outliers. It isn't good at demonstrating which of two well
behaving scripts is worse or better.

* In my mind the biggest issue is that mono scripts will appear 4x worse
than LSL scripts. This is really the reason I am hesitant to push a function
like this through before we have the ability for mono scripts to better
reflect how much memory they may use. We need more development time for any
solution on that front. Right now because a mono script could use 64k, that
is the only number we have available to count. Maybe it would be nice to
have an API to access number of scripts, number of LSL vs. Mono scripts,
amount of memory used and script time used. However we rapidly get away from
my desired philosophy of minimal interfaces.

 - Kelly

On Wed, Sep 29, 2010 at 2:51 PM, miss c <miss_c_27 at yahoo.com> wrote:

> This again isn't that useful because you cant accurately guess how many
> scripts the person is wearing because of the memory difference.  Secondly
> the laggiest script with every lsl call in the world would still only
> register at 16k.  I think that what would make my body melt into a pool of
> happiness is a script usage per avatar, the calls coming from an avatar that
> put strain on the server because some LSL functions are more evil than
> others.  I don't know how complex something like this would be to do.  At
> least with the script counter I know accurately that Mr. Cybernetic has 1534
> scripts in his suit and each script takes up .02 ms of memory if there isnt
> strain on the sim.  Did you know there are some resizing scripts that have
> chat listeners, OMG, someone go shoot those designers.  :p
> But I want to thank you so much with everything in my soul that your
> attempting to find a solution to this problem, just for your attempt I
> completely adore you, please don't stop!
> :p
> Miss
> ------------------------------
> *From:* Bryon Ruxton <bryon at slearth.com>
> *To:* Kelly Linden <kelly at lindenlab.com>; miss c <miss_c_27 at yahoo.com>
> *Cc:* opensource-dev at lists.secondlife.com
> *Sent:* Wed, September 29, 2010 4:33:30 PM
> *Subject:* Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count
> feature request
> Sounds good to begin with! The caveats you mentioned are not really
> problems to be concerned too much about.
> I would just suggest llGetObjectMemory(key id) for the function name.
> Perhaps a list params with SCRIPT_COUNT and SCRIPT_MEMORY then SCRIPT_USAGE
> with the lower results for mono scripts later on...
> On 9/29/10 2:00 PM, "Kelly Linden" <kelly at lindenlab.com> wrote:
> So I was playing with the following LSL function in a sandbox yesterday and
> I like it, but I'm gonna guess not everyone will.
> integer llGetScriptMemoryTotal(key id) returns the total script memory used
> by all scripts in the object or for agents the total script memory used by
> all attachments combined. Only works for objects and avatars in the same
> region.
> Potential problems with it:
> * Dyslexic naming weird it is.
> * No permissions checks, anyone can view the sum for anyone / any object.
> Since this is the case for the viewer feature it seems like adding any
> restrictions will just leave people still wanting the viewer hack version.
> * No detail information. I think this is best when used on anyone not
> yourself for privacy reasons. And we do have the UI for finding
> per-attachment details on yourself. So maybe not an issue.
> * Reports 'reserved' script memory. A mono-script will report 64k while an
> LSL script will report 16k, when really the mono script may be using less
> (mono scripts average 8-10k last I checked, in actual usage). Being able to
> report lower results for mono scripts is gated on other development work not
> currently in progress.
> * It doesn't seem like a very complete API.
> On Wed, Sep 29, 2010 at 12:47 PM, miss c <miss_c_27 at yahoo.com> wrote:
> Still need a script counter *hides*
> What I am probably going to do is get my husband to build me a personal
> version of 2.2 with mesh and the script counter.  That doesn't help everyone
> else though.
> ------------------------------
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100929/cb74d30d/attachment.htm 

More information about the opensource-dev mailing list