Timer Lag Concerns?

I am not a sim owner and so have no way I know of for checking the effects of script lag apart from what I can see around me, but I was wondering how much lag does a timer in a script actually cause?

Basically I have made a 'camping for credit' system that can hold 50 registered users at any one time, and I want to delete people from the system if they are absent (ie not camping) for 10 days. This means that I will have 50 timers running if all registration places are filled. Will this cause massive lag and if so would I be better having one timer and using link messages to spread the word to the individual campers file?

I think I already know the answer (which is a bummer cause I already finished it the other way' but if it is going to cause heavy lag then I will have to re-write it.
Thanks in advance.

I'd use a list to record the last time someone was present for every user, and one timer to check all of them...

I already have a file for each registered camper, mainly due to the fact that I want to record their names and lists cant be long enough to hold 50 names, so for the purposes of integrating with the rest of my system, it is easier stored in their personal file, but one central timer is definately implementable.

Well, I'm assuming you have your timer set to the full time with no incremented steps before it hits the time out phase.

In that case, with the timer essentially doing nothing at all, I don't see any reason why you couldn't use a separate one for each. It might not be the most efficient way to do it, but I'm assuming that you want each person to time out accordingly, and not have everyone get their time reset by one person not being absent, or relying on something that the 'user' is carrying (which would make it more hackable).

Essentially, let's assume you have all 50 spots taken...so you have 50 timers going, set to spring them into the removal stage of your credit system with the 10-day timer comes up. I would think that with a timer that long. That's assuming you don't have it going off too often, but I wouldn't think you'd need more than once a day really since if they do show up it just resets it.

My suggestion would be to try it by running the timers...even without the estate tools you can still get good judgement if it's going to be laggy or not with just a few trials.

I use timers all the time and the only times I notice them create lag is when I have them doing a lot of stuff really quickly, or if it's for a rezzer I have turned on - which that's more the nature of the result than the timer itself.

Cool. So basically they only cause any lag when they fire, so as long as they dont fire too often, then all is ok. Right?

I was planning on once an hour, but even so that is a fairly low level of timer activity isnt it? All together that would be less than 1/min. Plenty of scripts run constantly with a lot more timer activity than that without causing excessive lag dont they?

Well not exactly, they do create lag just in the nature of what they are doing while idle (counting until it's time to do something for example) I don't know the specifics, but this lag has seemed fairly minimal to me with more noticable results coming from what the timer Does when it fires than the timer by itself.

I've never dealt with 50 at once, however

My test recommendation would be to run the 50 timers in some sort of testing mode with the time decreased dramatically so you can compare firing vs not firing with a simple output that you can watch. I would do this where you plan to run these and just see what happens. That's my lazy suggestion heh.

You theoretically could break this down more with a 'master' timer that acts like just a time clock for the whole device, and have it check a variable for each of the 50 users each day to see who's expiring soon. This would mean you'd have to record their last date of activity on a variable, so that when the master timer fires, if the person's date is less than 24hrs' away, it will start up a secondary timer for that specific person on a faster rate and remove it from the master timer's list of people to watch. If they come back during that last day, then the script would remove their timer and add them back into the master's list.

That way you could theoretically still get 51 timers running at the same time, but for the most part it would just be one a few at once, with the master timer hardly doing anything at all most of the time.

When you run into a capacity limit like this, one thing to consider is a hybrid solution. For example, create a script that can deal with 10 names using one timer, and use five of them.

An advantage of this approach is the scalability. If you ever need to go up to 100, it's much easier than having to do it one at a time, or worrying about the lag impact at that level.

One issue with any script is that if it is active, even if just waiting for a timer to fire, a touch etc. it is being scheduled by the sim.

Once you get much over about 5000 active scripts in a sim, even if they aren't doing anything, you can see the sim start to lag.

Ok. If I go with the central timer option, then I have for the expiry part of my system one timer firing hourly that has to spit out a llMessageLinked and then 50 link message sets in the campers files.Is that laggier than 50 timers firing hourly?

Breaking the stored info down into sets of 10 and using lists might be do-able. (It would mean a complete re-write , but do-able). There is also a limit to how much data can be stored within a single script though, true? What is this limit? Would storing 50 names, 50 credit levels and 50 times until deletion be possible in one script or should I maybe use 3 scripts to store the separate record types.
If I go this way then one hourly timer could update all the records with one llMessageLinked and three link message sets. Does that sound like the lowest lag solution?

Another point.
Part of my 'Camping for Credit' system is obviously the camping stations themselves. At the moment all these have timers in too to record how long someone has been camping. Would a similar central timer counting seconds and llRegionSay with (I have eight camping stations) eight Listens be laggier than the eight separate timers firing each second?