This is something that I have never understood, and have always been a little skeptical about. I have heard many people saying that scripts which listen, especially on channel 0, are one of the biggest contributors to sim lag. Of course, anything that requires processing power is going to contribute to lag, but are listeners really one of the biggest contributors?
Even when there are tons of people around talking, the number of chat messages per second probably doesn't go above 5 on average. So each listen script would have the listen event triggered 5 times a second. For a computer that can process billions of instructions per second, I don't really see how that can have any significant impact.
Is there something I'm missing?
Update:
I just did a small test. I figure that most listen event handlers will tokenize the string and then check each token to see if it is a known command (probably will only check the first token, actually). Since in most circumstances, the message is not a command to that script, that is as much as it needs to do.
I wrote a program that tokenizes the string "This is a test message that will be processed by this program." and then checks whether each token is equal to "command", and reports how many times per second it is able to do that. Averaging over 120 seconds, it did it 101963 times per second. This is running on a machine here at school, and I'm not sure of the CPU speed. The OS is Solaris and the CPU type is Sparc. Also, my process was only getting 20% of the CPU.
Granted, this wasn't a very good test since there are so many unknowns, but at least it shows that there would have to be a lot of listeners to slow down the CPU.
Subscribe to:
Post Comments (Atom)
3 comments:
It's most likely true that server-side code can determine which listeners to serve the data to fast enough that we'd never notice no matter what the volume of data, but after that data is served to a script it is processed by a very slow and inefficient vm.
So if you have 20 animation overrides listening on channel 0 to anyone, and 20 hug scripts doing the same, for example, then you have 40 interpreted scripts running at far below native-code speed trying to handle that data. And with each of those scripts there is likely a lot of overhead.
This is probably why the filtering parameters to llListen exist in the first place : To reduce the number of times the server has to switch the processing from the fast and efficient native code to the slow and horribly inefficient lsl script code.
That's my best guess as to why it's commonly believed that listeners cause lag. I have some other thoughts on the subject as well, but I haven't had time to think them through well enough to put them into words.
That makes sense. Working on the scripts for my Go board has made me realize just how slow these scripts run. Now I understand how the claims of Mono being over 1000 times faster could be true.
Another thing to keep in mind is that for every possible listener, there needs to be an "in range" test to see if the listener could even receive any of the data in the first place. This is most likely done as a "3D point in sphere" test.
A whisper extends 5 meters, a regular typed message or llSay message goes to 20, and a shout goes to 100.
For each potential listener, you need to calculate the vector distance from the source to the listener. This requires 3 multiplies, 2 adds, and three subtractions. That gives the distance squared, which can then be tested against the square of the radius.
While that's not going to take much time when done by the server's native code, it's something to factor in. I doubt that it has any significant impact, I just wanted to point out how there are so many things to consider.
Post a Comment