Question re: listens

That's a very tough question to answer given a limited amount of context. How often are you utilizing the open handle for communication? Is it inactive for an extended period of time? Are your communications caused by a certain event occuring?

==Chris

The thought of 10+ listeners in one object give me the heebie jeebies..

Might want to look at 1 listeners and some linked messages for the rest..

I know there is big hype that the higher channel listeners are less lag producing but I haven't noticed it helps all that much when there are masses of them.

This subject is near and dear to me of late as I'm working on a project that needs massive numbers of reactive elements, and listens are the only option for me. I've got a little over 300 of them at the moment, with more to come, and each listens on two channels, one that is common to all of them, and one that is unique. The common channel is never used unless I'm updating the scripts or doing other maintenance tasks like that. The unique channel is used only when an attachment or free-roaming element is over the object, and there are few of those. So most of the time, these listening objects sit idle.

I did a lot of tests in an empty sim on this method, creating hundreds of these objects and watched the sim performance. But determining the impact of such systems is difficult. While 800 of them in an empty sim as fine, it looks like it's not good now that the sim has more going on in it. While I wrote this, I did some tests...

The sim FPS was around 850 with just me in it. I had 316 of the objects. I made 400 more and the sim FPS dropped to 350. That won't be acceptable with more than 5 people in the sim, I'm sure. I wasn't planning on adding a full 400 more, but construction is far from done here. So I'm now looking at having to redesign the whole system.

I don't understand why scripts listening to silent channels should be causing so much of a hit to the sim. Any Linden programmer want to clue us in? Is this something that will change for the better when the rumored switch to Mono takes place?

/me goes back to the drawing board to make all these objects scriptless...

UPDATE: I removed the common listen channel, and it made no difference. A simple script with a unique listen channel and a listen handler had the same effect. A script with a listen and no handler for it had half the impact. A script without a llListen call had no impact at all.

RESULTS: Even if it is NEVER triggered by a message, and even if it is on a unique channel, llListens have a significant impact on a sim's performace in large numbers.

What is float time? I use visitor counters, the default script, and I notice that the float time is 1.0. I took this to mean the frequency that it listens? I changed the float times to 10.0, assuming that it would listen less often and be less of a sim drain. Have I done anything productive or just been wasting my time editing this variable?

Juro, drop me an IM in game and I'll be happy to help you work through listen stuff if you still have questions.

Ugh - I do this same thing, although with about 38 listeners. They all listen on a high channel - but from what I'm reading here, that's somewhat irrelevant from a lag perspective.

The listeners I use are for changing the room decor on demand between a bunch of different textures. The walls are too far apart to link them all - although I'm seeing now that these listeners may be less than ideal.

For my purposes, a small delay is acceptable. And I only have the need to change the decor a couple times a week at most - usually for a special event.

Would I be better off having each of the wall prims use email instead? Does llGetNextEmail() load the server - assuming emails would only be sent to the objects if i wanted to change the walls?

If email is a better alternative - this'll be tonights project

I posted on the subject a long time ago:
/54/c8/25865/1.html
/54/f8/34253/2.html#post368737

Summary:

1) Having a timer is not significantly better than having a listen. What this means is using email on a timer may not win you anything.

2) The performance drain that you see with listens comes mostly from the fact that each listen() must be examined by every single chat statement going through a sim.

Multiple listens done by the same script are internally agregated into one listener. What this means is that changing a script from using 2 listens to 1 listen may not win you anything.

An alternative solution to your problem, without using listens and emails: use a script to set an pin, and use llRemoteLoadScriptPin.

That sounds brilliant, Francis.... Thank you!

I'm checking out the wiki on llRemoteLoadScriptPin and llRemoteLoadScriptPin. Its melting my brain - but I think its something within my capabilities

Is checking the sun's position in each of the scripts more effecient than this? Normally you see this for turning lights on at night and off in the morning, and that code is somewhere in the scripting library. No listens required...

depends entirely on how often the timer fires off.


Not entirely true.
1. According to Phoenix, locality and time are the first two factors that are checked before a listen is ever examined.
2. It's not just the sim. It's also child agents in range of listens near sim borders.


Depends on your filtering. If you have two different filters, it can't agregate. If they are the same filter, you can.


Decent advice.