Dormant timers and listeners don't add to script perf

I just added a timer and a listener in an empty sim and I was interested to learn that script perf wasn't impacted except when code by the listener / timer was triggered.


So, I duplicated the objects over several 100 times.. still nothing. (Though, when I said something, look out!)

Does this mean that listeners don't lag a sim unless triggered? Or is the lag simply not being shown on the sim stats list?

I remember doing this before, and sim FPS was impacted.

Problem with the new system is that you can't see the impact of scripts on performance anymore.

Script Perf is the number of opcodes per second that the VM is executing in that sim.
In the pre-1.7 world listeners impacted the sim performance, not because they were running a lot of opcodes through the VM, but rather because (AFAIK) the sim had to run every bit of chat text through a queue of listeners, check if they were within whisper/say/shout range, and execute their filters to see if there was a match.
I'm betting the way timers / llSleeps worked was also by checking a queue to see if it was time to trigger the event / resume script execution.
I have no idea what impact they have on the post-1.7 world and I would suggest postponing benchmarks until this branch is stable
Arguably, in the post-1.7 world scripts should be kept even more efficient, because you're not hurting the experience of half a dozen clueless clubgoers that will scream OMG LAG in the forums... you're hurting your own ability to run scripts.
And while it's entirely irrelevant to the clubgoing kiddies whether their new dance triggers this second or the next, scripters are kinda expecting some amount of timeliness from their systems, if only for purposes of responsiveness and interactivity.

Holy hell.

I assumed that at the WORST they were doing something like:

SELECT uuid FROM listeners 
  WHERE channel=$channel
    AND (name='$name' OR name IS NULL)
    AND (key='$key' OR key IS NULL)
    AND (message='$message' OR message IS NULL);

Or if it's not going through MySQL:

for(queue = listen_table; queue != NULL; queue = queue->next) {
  if(queue.channel == channel) {
    for(listen = queue.listens; listen != NULL; listen = listen->next) {
      if(listen.name != NULL && strcmp(name, listen.name)) continue;
      if(listen.key != NULL && strcmp(key, listen.key)) continue;
      if(listen.message != NULL && strcmp(message, listen.message)) continue;
      notify_script(listen.script);
    }
    break;
  }
}

The point is, there's a 1:1 message-channel relationship, so checking the channel FIRST and only every running further filters on THAT channel is so obvious and cheap an optimization I'd have had that in there from the start.

I remember the posts before 1.7 where people was happy that efficient coding would no longer be required, because scripts wouldn't lag any more. I was sceptical then, and my experience with 1.7 so far seems to bear that out. This doesn't apply for simpler scripts where response time isn't an issue. But for scripts that use/require any form of synchronization, it seems that you need to write even tighter code now than you did before. Sure, it doesn't lag the sim and the users on it, but it lags the script. Anything which requires multiple script communicating seems to run jerkier with 1.7 than it did before. At least, that seems to be my experience.

Maybe I'm just a sloppy programmer

I'm not an employee of LL, I do not know the exact details of what goes on inside their system and I didn't even put a lot of thought into that post
Ask other scripters, they probably have better info on this.