llEmail()/llGetNextEmail() "lag"

I heard third-hand that llEmail "causes sim lag". Unfortunately I can't get more clarity on exactly what the details of this are. I would guess that, sure, calling llEmail in a tight loop like an idiot would cause sim lag, and polling llGetNextEmail() with a .0001 delay between checks is going to cause lag.

Apparently this statement came from a Linden and therefore any object calling llEmail() on the sim is being looked at in a very negative light. I'm not sure whether the statement was more along the lines of "llEmail is evil avoid it at all costs" or "llEmail is frequently abused, use it with caution".

So I'm not asking whether sloppy, resource hogging code contributes negatively to sim performance. Duh, it does. My question is whether an *occasional* llEmail(), say on the order of 1 every 15 minutes once each from a set of, say, 15 objects around a sim, would cause *noticeable* sim lag. Same question for llGetNextEmail(). Is llEmail really that evil that a few calls here and there causes the sim to stutter??

There are certain vendors whose name I won't mention that are always showing up high on the script debug list on our sim. Like any networked system, they call llEmail, obviously. This is now being pointed to as *the* reason these particular vendors are so resource hungry. But I have a hard time believing that, instead suspecting bad coding (i.e. *excessive* llEmail/llGetNextEmail() calls or something else entirely). I have my own objects placed around the sim that call llEmail/llGetNextEmail once in a while and they always show up very low on the script debug list, so I have a hard time pinning blame on the email calls. Maybe that's proof enough, though it may be that the email calls cause sim lag in other ways than purely script time hogging.

Does anyone have any insight on how evil llEmail() and/orllGetNextEmail() calls really are in relation to sim performance?

One thing I haven't tried is to see if I can purposefully cause sim lag by calling llEmail/llGetNextEmail in tight loops in many objects just to see if I can really see a difference. As soon as the sim clears tonight I might do a few experiments

There are all sorts of issues here...

There are things for which you have no option BUT to use llEmail/llGetNextEmail. Using them slowly and sensibly in a small number of objects in a sim, just like when there's really no option an open listen on channel 0, having nice physics enabled objects colliding etc. will contribute to the load, but it's not too dire.

But let's say you're sensible, once every 15 minutes works for you... that's fine. Now you rez 117 of them on your 512sqm, so does everyone else in the sim (which is closer to the situation you're thinking of in a mall say, although a bit exaggerated). Suddenly there's 15,000 objects all polling once every 15 minutes... If they're roughly evenly distributed that's one every 3 frames or so... so there's a constant drain on the sim. If they cluster (and timers and script delays etc. aren't perfect, so they probably will a bit) you might find the situation that every second or so there's a huge load, the server slows down, buy transactions too and so forth...

I run a mid-sized shop. Because it works on a commission basis they have to use the vendors I supply. Quite deliberately they're not networked, although they do send emails out once a day about sales. There are probably 100+ vendors in the mall, the lag from just textures is high enough, adding extra scripting load as well is just asking for the sim to struggle.

There are, now, alternatives. You can use xml-rpc and llHTTPRequest to ping in and out of a sim and distribute your information that way. That's probably lower load, although it does require something out of world as well.

Think of it this way round: LL puts in the delays on the scripting calls based on the load they see for the functions. Some of those are loads that are quite predictable (moving prims, loading textures etc.) some we're less sure about how they've worked them out. But llEmail has been around for a while now (there's a note about scripts using it pre-1.3.5 on the wiki) and it's still got the 20s delay - which is a pretty good indication that's it's hard work for the system.

As to that delay, some scripters will get around it by putting 20 slave scripts that do nothing but llEmail in rotation, so that they can send one email per second rather than one per 20 seconds. Not only is getting around these limits bad, but it turns out that every script contributes in not insignificant amount to sim load in and of itself, regardless of whether it's actually DOING anything. Are these vendors you're looking at full of tons of scripts, Sasun?

No, it's actually a networked intra-sim teleportation system that I created that has a variable number of kiosks that communicate to a central server via llEmail. You drop in a notecard of destinations and textures into the server and all the kiosks display a grid of square "buttons" with the textures from the server on them. When a user clicks the texture he poofs so that location. So imagine a grid of textures of store logos or store fronts. You click and you're there.

All the TP destinations and associated textures are maintained on the server so it's super easy to update all the TP destinations from one spot. Since I don't know how many "kiosks" will be around the sim (they can be dropped at will by the owner) the kiosks need to poll the server once in a while for updates. I can limit the polling to something real light, like once an hour or even once a day so that the kiosk scripts are just sitting idle on a timer all day.

Each kiosk contains one master script and one script for each button, so if there are 16 TP destinations on your notecard, each kiosk will have 16 scripts, but each one is sitting idle waiting for a link message from the root script (in case there was a change on the server and the buttons/destinations/textures need updating). The root script is the only script that sends an occasional email to the server. The server doesn't reply if the kiosk is already up to date.

They are always super low on the debug list so they don't seem to be using much script resources other than the overhead per idle script.

Whilst I think something like that should be OK, and if it's your sim then there's absolutely no problem with it... there are alternatives.

For example you designate a server location, each tp'er rezzes a courier that flies down (llSetPos() type), queries the server about locations and flies back. You could even do it so that there are two courier systems, each location when newly rezzed and/or moved rezzes a courier that reports the new position to the server, which then rezzes 1+ couriers to update the network, since it "knows" where every tp point is.

You could also have the tpers network by shouting on some obsure channel with a nicely filtered listen, if you want to be really good about it you turn the listeners on for (say) 1 minute every 15 minutes so there's not a continuous drain that way, but I think an always on listen on some large negative number channel isn't that dangerous. If you have any locations more than 100m away from their closest neighbour you would also need a chain or repeaters and/or the courier system for them.

Whilst the llEmail distribution network should be OK, there are alternatives (the rez one is also moderately sim heavy, but it only sends updates when needed), the listener is a continuous, negligable drain. It sounds like you've got your head screwed on right and it is one place that I wouldn't have a problem with it at all.

NB I don't know, but I'm moderately sure that receiving emails isn't too painful, it's sending them that really hurts.

So is llHTTPRequest any better than emailing? HTTP does does seem to have any delay. The data could then be sent to a email form and processed somewhere else. But wonder how this affect the Sim.

The honest answer is, until you find a sim you can test this in I'm not 100% sure.

One way, if you don't happen to own an empty island, would be to script something to send the data by email and the same data by HTTPRequest. By all means put in replies, but keep the processing for that the same.

Put each script (or script family) into an attachment triggered by a touch_start(). Take all your other scripted attachments off, go stand in a void sim. Attach one then the other (only one at a time) so you get a resting state 'cost' for each. Then send the messages, process the replies, monitor the sim's ips whilst you do this. Rinse and repeat...

I have a strong suspicion that llHTTPRequest will be less intensive than llEmail, faster in both directions and so on, but it is only a suspicion at this point in time. I can say from my tests it's a damn sight FASTER, even if you have a script farm for sending the Emails out, turn around consistently <2s compared to up to 10s (and occasionally minutes to hours) to the same location.

The discussion in this thread has been spot-on. As stated, "laggy" is very difficult thing to quantify, and it is very hard to say with any authority "x many llFoo calls generate y lag".

However, llEmail is much much more intensive that llHTTPRequest. That said, I realize that at this time there are things with llEmail that can't be done directly with llHTTPRequest. None the less, if you can host a PHP script on an external web server, you will generally be much happier running your communications through it with llHTTPRequest.