(Tekkie) Processing of Listens

Hi,

I've just been asking on the Scripting Tips group about the impact of Listen that never hear anything on the performance of a sim. The general impression seems to be that the server keeps all of the active Listens, no matter what channel they're on, in a single huge list and scans through it whenever any message is sent.

Firstly, is this true?

Secondly, if it is true, is it possible to consider having certain channels (0 is the obvious candidate, plus maybe some others as well) as "high performance channels" which have their own dedicated listener lists, rather than having their listeners wrapped up in the single huge list? Eg, a listen on (say) channel 10928 would go into the single huge list, but a listen on channel 0 would go into a completely seperate list devoted to channel 0. Thus meaning that when someone speaks on channel 0, the system need only loop through the smaller list of listeners that are definately on that channel to find anything it might need to call?

That's not the worst of it. Link Listens (listens for messages sent between linked prims)also have a constant drag on the cpu. They are as expensive to have enabled as any listen not on channel 0.

A 500 prim color changing dragon av with 500 link listen scripts (enabled but not actively used) uses 1/3 of the TOTAL script time that a sim can process before getting time dialtion!

The LSL messaging system is the most broken thing I have ever seen.

I would not expect any fixes though as they are working on completely replacing it. And hopefully that will be very very soon!

You sure you're not overstating the case? If it was that bad, sims with a lot of high-prim heavily scripted avatars... like Isle of Wyrms... would never have any script time available.

Here's what I want to see in this category:

llSetObjectAttribute(string name, string value);
string llGetObjectAttribute(key object, string name);

These would avoid the use of chat and listens for objects to just update static info that's rarely used.

llSetLinkParams(integer linknum, list params);
list llGetLinkParams(integer linknum);

This would allow scripts in the root prim to modify parameters in other prims directly, withoutthe need of slave scripts.

llSetLinkListParams(list links, list params);

This would solve the "but that's too slow" objection.

To the OP:

I don't think that anybody but the Lindens knows 100% for sure how the Chat message dispatch mechanism works. It is speculation, based on empirical analysis of sim performance that Listens on various channels cause about the same amount of usage when idle.

"Binning" listens in heavily-used channels might work, if the sim could bin them dynamically. IE, when the sim got 10 (or some other fine-tuned number) or more listens for a channel, it would create a new list just for that channel. However, simply segregating listens into a "Channel 0" bin and an "everything else" bin probably would have next to no impact on listen performance. The majority of listens nowadays are actually on private channels (quite a few of them negative channels, in fact), but 0 probably still has the mode in terms of number of listeners (every agent is pretty much a channel 0 listener object).

Concerning link_message overhead:

link_messages are at least an order of magnitude more efficient than chat messages, because the scope of the sent messages is limited to the object's link set, and not to the global simulator prim set as a whole (unlike chat messages).

That said, yes, a prim-changing Dragon av is very laggy, but not so much because of the link_messages, but because there are 500+ SCRIPTS running at a time for each av present. Normally, these scripts aren't doing anything, and we've had 40-50 full avs in the same sim at one time, which does lag it bad, but it holds up (or did in the past, anyway). It used to be worse, as the older models has REGULAR LISTENS in each prim; even on a private channel, they were significantly more laggy.

No matter what, I am with optimizing the VM as much as possible, so whatever will help would be appreciated. I am with Argent, though. I would DEARLY LOVE to be able to control the appearance of all prims in a link set from the root (or any single prim in the link set). I think that was one of my "top 5 things to improve scripting" when that forum was still here. llSetLinkPrimitiveParams 4tw!

*ahem* Is there actually such a thing as a "link listen"?

It does not seem likely from the way the code is structured that having a child prim receive linkmessages involves a resident process at all. It doesn't work anything like the way chat listens do; there is no such function as llLinkListen.