• 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
Return to search
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
becky pippen made changes - 22/Aug/08 09:20 AM
Field Original Value New Value
Link This issue is related to by SVC-1276 [ SVC-1276 ]
becky pippen made changes - 22/Aug/08 09:23 AM
Link This issue is related to by SVC-1398 [ SVC-1398 ]
becky pippen made changes - 22/Aug/08 09:24 AM
Link This issue Relates to SVC-1959 [ SVC-1959 ]
becky pippen made changes - 22/Aug/08 09:29 AM
Link This issue is related to by SVC-1959 [ SVC-1959 ]
becky pippen made changes - 22/Aug/08 09:33 AM
Link This issue is related to by SVC-1959 [ SVC-1959 ]
becky pippen made changes - 22/Aug/08 09:41 AM
Summary Slow LSL-recompiled scripts after Mono deployment Slow LSL-recompiled scripts in Mono regions
Description 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.

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 .
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 .
becky pippen made changes - 23/Aug/08 06:32 AM
Status Open [ 1 ] Closed [ 6 ]
Resolution Cannot Reproduce [ 5 ]
Sue Linden made changes - 13/Nov/08 12:12 PM
Workflow jira-2007-12-22a [ 58393 ] jira-2008-11-14 [ 83283 ]
Sue Linden made changes - 13/Nov/08 04:57 PM
Workflow jira-2008-11-14 [ 83283 ] jira-2008-11-14a [ 96261 ]