Last week I submitted a question asking why my server resources were used up by a small number of objects doing timer() events once a second. http://forums.osgrid.org/viewtopic.php?f=14&t=4261 I thought there was a fundamental limit on how many timers() you could have happen in a small amount of time.
This week I have new data: It is not the timer() events! It is what I was doing in the timer event, but I still don't see why:
Here is the setup: my object is made of two prims, the timer() event is called once a second. In the timer() event I change the size of both prims. I rez 25 of these in an almost empty sim. (0.7.1.1 release, quad core server box with 6GB memory, little else running on the server).

- If both are regular prims (sphere, cylinder) there is no measurable decrease in sim FPS.
- If one of the prims is a simple sculpt (apple) the FPS drops from 56 to 30.
- If one of the prims is a complex sculpt the FPS drops from 56 to 16.
- If one of the prims is a torus twisted into a helix, FPS drops from 56 to 3!!!
- If I stop the scripts in all 25 objects, the FPS goes back to 56, even with the complex sculpt.

The complex sculpt is a helix twisted around 8 times. I tried switching to a torus twisted into a helix by revolving it 4 times in the build menu, and things got WORSE. I can now demonstrate the problem with only 5 copies of the object running at once. In all cases the same transparent texture map is displayed on the prim, repeated the same number of times. I tried switching to the default blank texture with no transparency and this did not change the statistics.

So my question is: Why does changing the size of a sculpted prim or a torus use up so much of my server resources? Is there something I can do to get around this? Can I submit this as a bug?

I decided to submit this as a bug report (http://opensimulator.org/mantis/view.php?id=6080) and in the process of writing a small script to demonstrate the problem, I found a workaround!
My script originally changed the size of a prim through a sequence of fixed sizes from 0.5 to 20.0 in steps of 0.5. Curiously, the first time through the sequence the SIM FPS dropped down, but the second and subsequent times through the sequence the FPS came back up. I'm guessing that the system is caching different sizes of the prim and this is the source of the slowdown. To make the script continue to hold down FPS, I changed the demonstration program to add a small random number to the initial size. Now it continuously drags the SIM FPS to its knees and hopefully this will allow the developers to investigate the problem.
So I decided to take advantage of the cache. I modified a version of my original growing tree script to truncate the prim size to the nearest integer. Now there are fewer size changes happening, and all the trees in the forest use identical sizes but at different times. (They all start at random sizes). I installed a forest of 120 trees, all growing and changing the sizes of their prims with no drop in SIM FPS! Before this change I could not rez 10 of them without noticeable lag!
Problem solved!