* 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...@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 <br...@slearth.com> > *To:* Kelly Linden <ke...@lindenlab.com>; miss c <miss_c...@yahoo.com> > *Cc:* opensource-dev@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" <ke...@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...@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 >
_______________________________________________ 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
