• All submissions to this site are governed by Second Life Project Contribution Agreement. By submitting patches and other information using this site, you acknowledge that you have read, understood, and agreed to those terms.
Issue Details (XML | Word | Printable)

Key: SVC-2903
Type: Bug Bug
Status: Closed Closed
Resolution: Cannot Reproduce
Priority: Low Low
Assignee: Unassigned
Reporter: becky pippen
Votes: 0
Watchers: 3
Operations

If you were logged in you would be able to see more operations.
2. Second Life Service - SVC

Slow LSL-recompiled scripts in Mono regions

Created: 22/Aug/08 09:16 AM   Updated: 27/Aug/08 06:06 AM
Component/s: Scripts
Affects Version/s: Mono Beta
Fix Version/s: None

Environment: Second Life Beta Server 1.24.0.94831 compared to Second Life Server 1.23.4.93100
Issue Links:
Relates


 Description  « Hide
Some existing scripts, especially those with a lot of string parsing, math, or algorithmic complexity, run slower than they used to after being re-compiled with the LSL compiler option in a Mono-capable region.

Background: For the majority of scripts, the fastest execution speed has been limited either by the built-in delays in some library functions, or by how the sim throttles the rate at which event handlers are triggered. That's the case anyway when the processing inside an event hander gets done faster than the rate at which the sim allows that event handler to be triggered. For example, after the Mono deployment, scripts still receive no more than 22 timer(), touch(), or sensor() events per second, and no more than about a dozen listen() events per second, just like before. Scripts like this will appear to run at the same speed as before.

However, if a script executes a relatively long sustained loop of code in a single invocation of an event handler, so that the time spent inside any one invocation of the event handler is much longer than the usual time between event triggers, and if delayed library calls are not used, then the upper limit on execution speed becomes dependent on the speed of the in-line LSL code, operators, casts, control structures, function calls, and all other core language features used. Those are much slower now.

This is a little surprising because we had thought that the LSL compiler option in Mono-enabled regions would continue generating the same byte code and we thought the LSL VM back end run time would continue running the byte code in the same way. But some timing measurements show that that's not the case – LSL statements run slower when recompiled by the LSL compiler in a Mono region.

A few examples:

  • Every function call overhead is now more than twice what it used to be (0.88 ms/call, was 0.33 ms/call)
  • Most math operators are less than half as fast as before: the statement vector v = <PI,PI,PI> + <PI,PI,PI> * PI; now takes 1.1 ms to execute, was 0.43 ms.
  • Most non-delayed LSL library calls take twice as long to execute: llGetInventoryName() now takes 1.4 ms to execute, was 0.52 ms. llGetPos() takes 1.05 ms now, used to take 0.44 ms.

More documentation of the raw timing data is at http://wiki.secondlife.com/wiki/User:Becky_Pippen#LSL_Timings_and_Rates .



 All   Comments   Change History      Sort Order: Ascending order - Click to sort in descending order
Maggie Darwin added a comment - 22/Aug/08 03:53 PM
Scary, if true, that a script might have to chose between memory inflation and decreased execution performance.

Jahar Aabye added a comment - 23/Aug/08 04:15 AM
Just out of curiosity, are you comparing values with the precompiled values in the same region, or with the values you were receiving on the main grid? The reason I ask is because it is possible that part of the problem may simply be with the Beta Grid itself.

Long sustained loops of code within an event handler can cause some serious lag, and class 4 sims tend not to like too much script lag.

That being said, I'll certainly try recompiling some scripts in LSL in mono regions and checking. In previous tests I have tested pre-compiled LSL scripts to copies that were compiled to Mono and found no difference between those two in terms of script time, but I didn't try to recompile/re-save the LSL versions of the scripts in that sim.

I know that there are a few changes in how even the LSL compiler will be behaving - compiling scripts server-side, for instance - so maybe there is a bug in the new behavior somewhere. Certainly it is possible that it has not been caught because few people were recompiling scripts to LSL in mono regions.


becky pippen added a comment - 23/Aug/08 06:32 AM
Jahar, that's it! Some more testing shows that the main grid executes LSL core language elements about 2.5X the speed of the preview grid. I never would have imagined there would be that much difference. The numbers all match up now, so I'll gladly close this issue as "cannot reproduce."

Maggie Darwin added a comment - 23/Aug/08 08:15 AM
Ew. That makes it a poor place to find timing-sensitive bugs.

I hope the H4 pre-testing wasn't done in the same environment.


Jahar Aabye added a comment - 27/Aug/08 02:29 AM
As far as I know, I believe that the Beta Grid sims are running on Class 4 servers. Class 4 servers tend to slow down when trying to run too much at once. I remember when we (briefly) moved our combat arena to a Class 4 sim while our new full-sim arena was being built, and it was horrible. We had to be even more strict than usual about what was and wasn't allowed to be used there, because it didn't take much extra script time to start causing some serious lag.

Unfortunately, I don't think that you're going to be able to convince LL to put their brand new servers onto the Beta Grid where they'll barely be used. Until that happens, your best bet is to simply make sure that you're comparing stats and times from within the same grid, preferably even within the same sim.


Maggie Darwin added a comment - 27/Aug/08 06:06 AM
@Jahar--

Perhaps LL doesn't consider the quality of the beta environment a priority. But every difference between a test environment and a production environment increases risk that serious defects will find their way into production.

Doing betas on-the-cheap may be a false economy, when one serious server defect slipping through the QA/beta process can force many manhours of work on a rolling restart and impede the productivity of a very expensive developer team.

Hardware costs far from the biggest component of software development.