LSL Listen Mono Testing

I just did some Mono testing specifically with listeners, and came up with some interesting results. First I did a basic ping test. One object would start a timer and say "ping" to another object which would then say "pingback", and the original object would report the time when it received the message back. Averaged over 200 tests, without Mono the ping time was 0.066478 seconds. With Mono, it was 0.088936 seconds. I ran the tests multiple times, switching back and forth between Mono and non-Mono to make sure this difference was caused by Mono and not by other changes in the sim.

Next I took Robby's idea and had one object say "start" then "junk" 500 times then "finish". Another object would start a timer when it got the "start" message and report the time when it got the "finish" message. First, I used an unfiltered listener, so any messages sent on that channel would be forwarded to the script. The sender reported that it sent "finish" 0.600243 seconds after it sent "start". The receiver reported 33.476112 seconds between hearing the "start" and "finish" messages. I then recompiled with Mono and ran the test again. This time all the messages were sent in 0.178058 and received in 44.580690. The sending was over 3 times faster, but the receiving was slower with Mono.

Now I modified the script to only set up listeners specifically for "start" and "finish" messages. Without Mono, they were sent in 0.600193 seconds and received in 0.644574. With Mono, 0.133408 and 0.133169. All these numbers have taught me two important things: 1) USE FILTERED LISTENERS!!! 2) ESPECIALLY USE FILTERED LISTENERS WITH MONO!!!!!

Now comes the fun part. I copied the unfiltered listener so that there were 25 of them. Each of them ran at about the same time as the single listener. With 100, they still ran about the same. With 1000, still the same. With 10000 (I'm serious...screenshot below) it was finally a different story. First, the time the sender reported to send the messages shot up to 1.916057 seconds. From that number, I estimated it would take 10 minutes for the listeners to finish. I waited for 15 minutes, expecting a Linden to show up and wonder what the hell I was doing, and still there was no response from the listeners.Notice "Script perf" is 0 ips. I'm guessing they just haven't updated that to count Mono instructions.

With the filters, there wasn't much of a change until 400 prims (I increased the number of prims differently). At that level, the listeners finished between .133783 and .201377 seconds, but one of them took 45.042740 seconds, which is so close to the time for the unfiltered listeners it almost makes me think the server panicked and just started handing that one script all the messages. I doubt that's the case, though, because then scripts which used filters and as a result didn't have to check the incoming message would experience errors if they started getting unfiltered messages. At 800 prims, the range was .156157 - .224534, again with a single script reporting at 46.228270. At this point, I didn't go further because looking through a log of 800 messages was getting difficult. Looking back at the data from the unfiltered runs, there was similar variance in the times as seen here, but when it is taking 45 seconds it is much less significant.

One final weird behavior that I noticed while recreating these tests for the Jira issue (see below). I went back to the ping test and added filters for "ping" and "pingback". I didn't expect to see any difference, since all the messages sent are "ping" and "pingback" (on different channels, so that is already filtered). Indeed, there was no difference when not using Mono. But with Mono, it took longer! The time increased to 0.101741, which is an increase of about .02 seconds or a 25% increase.

In conclusion, I am definitely going to use filters all the time now. I have created a Jira issue about the performance decreases with Mono. Now what can I test!? :P