[#SVC-1862] Listen event performance worse using Mono

2. Second Life Service - SVC

Listen event performance worse using Mono

Created: 17/Mar/08 11:11 AM Updated: 10/Apr/08 06:38 AM

Return to search "1.21 Issues"

Component/s:

Scripts

Affects Version/s:

Mono Beta

Fix Version/s:

None

File Attachments:

tests.zip (1 kB)

Issue Links:

Relates

This issue Relates to:

~~SVC-1398~~ Mono beta - link messages are 2 times slower under mono

This issue is related to by:

~~SVC-1276~~ Mono issues

Linden Lab Issue ID:

DEV-13090

Description

« Hide

Test 1
--------
A "sender" object says a message on a chat channel. A "receiver" object hears that message and says a response on a different channel. The "sender" hears the response and reports the time elapsed between sending the original message and hearing the response. The scripts provided do this 200 times and report the average time. To reproduce, put "test1_sender.lsl" (attached) in one object and "test1_receiver.lsl" (attached) in another. Touch the sender object to start the test. Run the test compiling the scripts with and without Mono.

My results:
Without Mono: 0.066599
With Mono: 0.088832

Test 2
--------
In this test, the "sender" object will say "start", then "junk" 500 times, then "finish". The receiver will start a timer upon hearing "start" and report the time elapsed upon hearing "finish". Note that the sender will also report the time taken to say all the messages. To reproduce, put "test2_sender.lsl" (attached) in one object and "test2_receiver.lsl" (attached) in another. Touch the sender object to start the test. Run the test compiling the scripts with and without Mono.

My results:
Without Mono: Sender: 0.622370, Receiver: 33.462070
With Mono: Sender: 0.222209, Receiver: 44.583270

With Mono, the messages are sent quicker, however they take longer to be handled by the receiver.

A note about filters
-------------------------
With Test 2, by changing the listeners to filter only for the "start" and "finish" messages, the receiver then takes about the same amount of time as the sender, and there is no noticeable difference between Mono and non-Mono. With Test 1, however, adding filters for "ping" and "pingback" make no difference with non-Mono compiled code, however when compiled with Mono the time actually /increased/ to 0.101741.

Description

I have been doing some testing in the Mono beta grid to test the performance difference between Mono and the old VM using various operations. I have actually found that the handling of listen events seems to be slower with Mono. Below I will describe two tests that demonstrate this, and I have attached the LSL scripts (zipped) so that others can try to reproduce my results. I ran these tests in Sandbox Cordova MONO. Test 1 -------- A "sender" object says a message on a chat channel. A "receiver" object hears that message and says a response on a different channel. The "sender" hears the response and reports the time elapsed between sending the original message and hearing the response. The scripts provided do this 200 times and report the average time. To reproduce, put "test1_sender.lsl" (attached) in one object and "test1_receiver.lsl" (attached) in another. Touch the sender object to start the test. Run the test compiling the scripts with and without Mono. My results: Without Mono: 0.066599 With Mono: 0.088832 Test 2 -------- In this test, the "sender" object will say "start", then "junk" 500 times, then "finish". The receiver will start a timer upon hearing "start" and report the time elapsed upon hearing "finish". Note that the sender will also report the time taken to say all the messages. To reproduce, put "test2_sender.lsl" (attached) in one object and "test2_receiver.lsl" (attached) in another. Touch the sender object to start the test. Run the test compiling the scripts with and without Mono. My results: Without Mono: Sender: 0.622370, Receiver: 33.462070 With Mono: Sender: 0.222209, Receiver: 44.583270 With Mono, the messages are sent quicker, however they take longer to be handled by the receiver. A note about filters ------------------------- With Test 2, by changing the listeners to filter only for the "start" and "finish" messages, the receiver then takes about the same amount of time as the sender, and there is no noticeable difference between Mono and non-Mono. With Test 1, however, adding filters for "ping" and "pingback" make no difference with non-Mono compiled code, however when compiled with Mono the time actually /increased/ to 0.101741.

Show »

All

Comments

Change History

Sort Order:

[ Permlink | « Hide ]

Colin Kiernan added a comment - 17/Mar/08 11:18 AM

I wrote a more verbose report of these tests on my blog:
http://colinkiernan.blogspot.com/2008/03/lsl-listen-mono-testing.html

[ Permlink | « Hide ]

Gordon Wendt added a comment - 17/Mar/08 11:19 AM

Interesting, but if filtering for just the two messages makes a difference that would mean that the delay isn't in recieving the message (which should be faster if the message is sent faster) but in the handling of the message.

[ Permlink | « Hide ]

Gordon Wendt added a comment - 17/Mar/08 11:23 AM

reading you're blog post I'm wondering if the length of the message and/or the filter (both of which need to be processed by the listener) might factor in to this, I'll try later to run some tests on this and if I can get a good working model I'll upload scripts for it.

[ Permlink | « Hide ]

Colin Kiernan added a comment - 21/Mar/08 09:02 PM

The filtering makes a huge difference in the time taken to run the entire test, because the script is only delivered 2 messages instead of 502. The issue, though, is that the processing of the same number of messages takes longer with Mono. With so few messages, the difference between the run times of the Mono and non-Mono script are not noticeable, but I would bet that there is still a difference.

[ Permlink | « Hide ]

Gordon Wendt added a comment - 22/Mar/08 01:45 PM

I brought this to Periapse's attention at office hours yesterday and he said he'd (or I should, I don't remember) bring it to babbage's attention but that they would look into it so that's progress at least I guess.

[ Permlink | « Hide ]

Jeadeen Niles added a comment - 25/Mar/08 08:53 PM

I have been seeing a notable difference in attachment response when using chat commands via llWhisper to llListen on a negative chat channel. But, I am on the Main Grid. I was wondering if it could be related or do I have a seperate issue that is similar? It was all working fine up to about a week or so ago, then the attachments I was working on started taking minutes to respond rather than seconds.

[ Permlink | « Hide ]

Lee Ludd added a comment - 26/Mar/08 02:54 PM

I wonder if the difference described here is due to difference in message length. Mono uses 16 bit characters; lsl uses 8.

[ Permlink | « Hide ]

Strife Onizuka added a comment - 26/Mar/08 04:19 PM

@Lee: The easy way to test that hypothesis is to rerun the tests with strings made up (exclusively) of Two-Byte UTF8 characters (characters in the range [128, 2048) ).

[ Permlink | « Hide ]

Jeadeen Niles added a comment - 27/Mar/08 12:50 PM

The delay that I noted on the Main Grid has finally cleared up. I apologize if my comments didn't belong in this issue.

[ Permlink | « Hide ]

Colin Kiernan added a comment - 29/Mar/08 05:23 PM

I tried running the tests with different string lengths, and there was no significant difference.

[ Permlink | « Hide ]

RobbyRacoon Olmstead added a comment - 29/Mar/08 05:48 PM - edited

How is this linked to ~~SVC-1398~~ (link messages are 2 times slower under mono), exactly?

I could see it if it was because Mono queued events are handled slower, but in any case the connection is not obvious.

[ Permlink | « Hide ]

Colin Kiernan added a comment - 07/Apr/08 08:48 AM

I can confirm that this is now fixed on the Beta grid. Thanks Lindens!