Inter-object comm efficiency

Hello! I was wondering if you could help me clear up a few things regarding inter-object comm efficiency.

I'd like some opinions and/or explanations when comparing listen to Email. Since these are really the only 2 options for communicating between objects(save for the llRezObject parameter, but I'll get to that later).

When simply trying to communicate between objects at any time(that is not just on rez, but more frequently), what is the better way to go? Is it better to use listens or is it better to use slave scripts in order to work around the Email delay and use that? What causes less lag? Is Email fast enough(even with the slave workaround) to ensure that the receiving object will receive it almost immediately just as it does with a listen?

Next to that I am also curious about passing on data to rezzed objects.. Passing a key or a string converted into an integer and then recovered by the target script. I am not sure if it's possible to do this with a string, but I know that part of a key could be passed down(I doubt a whole key could be, since it takes up more data than 32 bits) if you were to take say one of the 4-digit sections of the key, convert it to decimal, pass it through the on_rez parameter, then convert it back to hex and use llSubStringIndex() to match it to another detected key in a sensor for example.. This would be very efficient as the likelyhood of finding 2 avatars/objects with the same middle section of a key in the same place would be next to non-existant. The question is.. Would converting it to decimal, then back to hex, then comparing it be more or less efficient(in terms of script time) than simply passing down the whole key through llWhisper() as soon as the object rezzes?

It is lighter and faster to use llRegionSay for local communication and keep email for remote. One router node (per region) helps keeping the script count low (example: 1 script per local node, a 20-script mail bank in the router). You'll have to encode the destination address in the message body and have the router know this is a remote address, then forward the message.
Email won't never be as fast as chat. Count on 1 sec in the good days, much more to infinite during rainy days.

I concur that llEmail() is a pig. But I am a little concerned that now, with llRegionSay() possible, it's the hammer suggested for all nails. If your script and everything it talks to is stationary and within a single sim, llRegionSay() is fine, but for many uses, llWhisper(), llSay(), and llShout() are less likely to lead to unpleasant surprises the first time your script encounters a sim boundary.

As for the original poster's idea of passing a substring of a UUID as an on_rez parameter, there's the remote possibility (one in 2**32) of a collision. (For what it's worth, I don't really think it matters which numeric substring of the UUID is used.) But if the script can survive such collisions, then it would be a lot faster. Indeed--perhaps superstitiously, based on the lslwiki comment "You can use a short llSleep delay in the rezzer object if your script isn't hearing it"--I've always had the rezzed object announce its presence before the rezzer talks to it (usually on a random channel passed as the on_rez parameter).

All told, an efficient inter-object llInstantMessage() would sure be nice to have, and would seem to cut out some major CPU use, for which llRegionSay() marks a beginning.

It is not. When it works, it works quite reliably. We had problems with mail queues suspended in some regions, and other temporary glitches. A HTTP/PRC combination is worst since the RPC proxy seems overloaded now.
I prefer the "whole sim/no cross borders" messenging over a "repeaters scattered anywhere". You don't always own a full sim to install repeaters at optimal points. You can connect adjacent sims with a llRegionSay/llSay bridge, whose location is less critical.
Agreed.

(tries to think of something clever involving swine and lipstick) It's just that llEmail is really slow, which leads me to *suspect* it of having substantial overhead in its implementation--as if it's actually using a sendmail backend. If not, then maybe it is as close to the remote inter-object llInstantMessage() target as makes no difference.


Yes, absolutely: llRegionSay() is a real win. I'm only concerned that its current popularity not lead to uses where the less shiny old functions would be more appropriate.

Yes, there is a substantial overhead in the SMTP protocol over an instant messaging protocol. Sending a mail requires at least 4 bidirectional transactions (HELO, MAIL_FROM, RCPT_TO, DATA) with the mail server. Then again from the mail server to the mail client (LSL interface). Mail delivery is initiated from LSL (you need to call llGetNextEmail to receive a mail event), so another delay or a waste of resources if you poll to often.

From SL to SL, this may be quite fast because all mail is local (same domain). But it will never be as fast as llInstantMessage. Mails are queued in an intermediate host, generally running postfix. IM don't need to. Think seconds, not milliseconds (although i've never benchmarked llInstantMessage).

ADDENDUM: If you are interested in real performances figures, here are some locations of mail-enabled info kiosks. They are not much different from Pathfinder's ones. When you click, an e-mail is sent to the server and the server gives a notecard. They have been working reliably for monthes now. Response times are decent for human interaction, but may vary greatly with sim/grid/mail system load. None of these terminals are in the same region as the server.

Wild Vertigo 18,47,27 (Class 5)
area 51 159,22,26 (Class 4)
Gaia 145,171,26 (OpenSpace, low-perf sim)