llListenRemove vs llListenControl

heyas;

i hate listeners. i kill them regularly. :X


but zhao ii uses listen control to turn a listener on/off instead of killing it altogether. are both methods basically the same? is one better for reducing lag?

also on the portal wiki, it says that all listens are removed/cleaned up on state change. is that true?? i thought that listens were not properly cleaned up, which is why the need to liberally kill them a lot.

That is true it is effective and reliable.
Personally I never used llListenControl, maybe I will some day, but I use llListenRemove a lot

My guess is that llListenControl is better if you'll be turning the same listen on and off. Perhaps it's more efficient (which makes sense) -- otherwise, why would they have bothered?

In any case, this is a question you can quantitatively answer yourself.

Write a simple script that gets the time, posts a listen and deletes it 1000 times, and then chats the delta time. Then does the same but using llListenControl(). Compare the results and let us know what you learned!

Of course, find a sim that's very unbusy for your test, and run it several times to see how repeatable the results are.

I find Strife Onizuka's analysis in the Talk page () fairly compelling:

When LSL was designed many functions were created. Programing language programmers don't know what people are going to do with the language; they make arbitrary design decisions that may or may not be beneficial down the road. It's much more likely that the programmer thought someone would find llListenControl useful. The target events have a similar design strangeness. -- Strife Onizuka

I can see how it would be useful, but I don't see changing the logic of your program to use it if it doesn't happen to fit.

Presumably there is a greater server overhead for creating a new listen (llListen) rather than setting an existing one back on (llListenControl). There must also be a server overhead for holding open-but-deactivated listens. Without knowing the internal details of LL's servers we can't really judge the relative processing costs as a script would be 'in use'.

Most of my listens are for menu or object-object comms and I generate random channel-numbers for each use, create the listens and then llListenRemove() them on traffic or timeout. Fixed-channel comms are either so rare (av chat commands) that I create the listen on touch and later llListenRemove() it or so frequent (object-object) that I keep it open all the time.

Altogether that means I hardly ever use llListenControl()

as kear said, llListenControl is good for when you're turning the same listen on and off. probably good for positive number channels for avatars to talk on when needed. for llListen and llListenRemove, i use it more commonly with dialogs, to always have a random channel. good for when you have multiple copies of the same object out and want to control them individually

Correct -- the best we can get is one term in the equation, the measurable run time difference between the two. Even this isn't a processing time difference (unless we use 'top scripts'); it only measures the amount of real time, which could be different. But that's more information than none.

I agree with Argent that I wouldn't use a clumsy architecture to employ it; I'd only use it if it fits a good architecture.

But the fact that they implemented it is a clue that it's lighter weight. It isn't wise to provide a function that provides a subset of the functionality of another function unless it either (a) obviously simplifies coding for the user or (b) provides a significant benefit in efficiency.

Not that LL did everything right with LSL, but IMHO they did a remarkably good job in many ways -- too bad they didn't document it, instead leaving it to be implicitly defined by its behavior.