Jump to content

Zero spare time, 68% scripts Run, Frequent texture blurring


Vulpinus
 Share

You are about to reply to a thread that has been inactive for 3310 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

One can't help but wonder, when the heck did this creep into the code? The (silly) chat icons have been around since Viewer 2, and the chatbox widget is more or less unchanged since Viewer 3, yet the texture-thrashing problem seems to have grown markedly worse in the past nine months or so. This raises the possibility that patching the chat icon retention bug may reduce the pain but not fix a larger, more recent texture-thrashing problem -- unless the icon retention bug was a recent regression.

Link to comment
Share on other sites

Well, my zero spare time issue came back several days ago, having been around 5 to 7ms for a while. Total Frame Time is always over 22ms, usually around 22.5ms, which the wiki says is bad. I did not make any changes to my land/objects (well, I actually reduced some scripts but the change did not coincide with that) .

Support have said I'm one of the two highest script users in the region (I have the largest individual parcel - what a surprise; the rest are mostly much smaller rental lots) and gave me some links to read on reducing script usage. Hmm. Also said I should talk to my neighbours - yeah, right. I've tried. Only one, barely helpful, response. Doesn't help that they apparently can't even see the script list in about land - probably because of being rented I guess. That's why I keep asking support to look at the details and tell me.

I've asked for more details on the scripts in the region. If it's mine, I need to know and will deal with it, however I have pulled in all the heavily scripted furniture (stuff with MLP and Xpose for instance - how many scripts do they need?!!) and most of what remains is chairs with a single AVSitter script or similar, and things like light switches and doors/windows which are all single scripts per item and sitting idly most of the time. I've reduced my script count by 50% and it's made no difference whatsoever to the statistics window.

Most of the remaining scripted objects (chairs mostly) were put out long after this issue started for me, so unless we can find a rogue script I really don't think I'm the one hogging the CPU. I almost hope I'm wrong - I could fix it if I could find it.

The only thing I am unsure about is the door and window scripts, since I didn't write most of those. I use the Kool Door script. I do plan on rewriting the controls to run all the linked windows/doors from a single script in the root prim, but I'm currently trying to get my head around how to keep and update twenty-four sets of positions and rotations plus status without using an array*. A pox on the lack of arrays!

And my crows still keep freezing when I'm not looking at them. Such is life!

 

* Currently discovering JSON... hopefully a solution.

 

ETA: Forget the Kool Door scripts - I've just discovered llGetObjectDetails and checked out the script time. Two linked doors report as 3us Script Time, 28 linked report as 34us. I have about 100 doors and windows total in several linksets so that's still enough to make me want to write a single controlling script. It's not the doors killing everything though, even like this. I'm going to run my little tool on everything else now...

Link to comment
Share on other sites

I'd stay away from JSON if efficiency is any consideration.

Arrays are pretty much the same as strided lists, except you get to do your own array-indexing arithmetic. This is easier than the assembly language equivalent, and very similar to ancient implementations of LISP in which lists were the only data structures, so think of it as a kind of "living history" of computing.

Also, you may find you can store the information you want in the object descriptions of the linked prims. That's how very old linked door scripts worked (and then famously broke when the name and description fields shrunk, and the scripts had been using too-expansive texts). The advantage is that you don't need to keep anything in script memory, but rather use the "memory" of the object descriptions, readily accessible when touched (or from a list of link numbers, for windows to be thrown open from a remote control or whatever).

Still worth tracking down what's eating all the script time in your region. When support said you were "one of the two highest script users in the region" did they make clear they were talking about script count, or script time, or something else?

Link to comment
Share on other sites

All support said was they had looked in Top Scripts and I was "one of the highest two contributors" - nothing more specific. I've asked for further details. I guess it means I was the second highest though, otherwise they would just have said 'highest'.

I've been running my little 'Script Time HUD" on everything around me, and nothing in my parcel stands out. Everything I've scripted myself reads at between one and three microseconds per script at idle (as expected), and nothing else is high enough to be any concern in the numbers of them I have rezzed. A lot of things were less than one μs.

I had just one surprise - a single-prim, seats-four table and chairs which ran far higher at 33 μs for its six scripts than anything except an active MLPv2 engine. Maybe it was just a glitch - I'll check it again when I get home. I know Script Time is an average (over how long?) and nothing had been in use for a while when I measured it.

...

Yeah, I've had a good look at JSON and came to that conclusion. I've actually done arrays and linked lists in assembler (and actual machine code before I had an assembler) and briefly used Lisp, along with Forth, Algol and the usual suspects. Cut my teeth on a PDP11/34 back in the day! These days most of my programming is embedded C or C++  on microcontrollers.

I'll go the route of storing most parameters in the description fields of the linked doors/windows I think, along with just some live data in memory. Most data won't need updating unless I move things around after initialising the script anyway. I tend to procrastinate and try to make my programs both 'universal' and highly optimised; sometimes I need to just get on and write the darn thing to do the job at hand, lol.

Link to comment
Share on other sites

Well, tha's my window script done - saved about 90μs of idle time on my linked windows. Now it's just about 4μs (I needed to use two linksets).

Of course, even that's only a tiny fraction of what is going on somewhere in the sim.

The only thing I miss is a nice sound. I need to find a good sliding window sound to drop in there.

 

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 3310 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...