There are two other factors one has to account for:
1) number of scripts / event definitions at all
That's plain: The more event definitions mIRC has to get through, the longer it will take till all have been processed. And in the worst case, some "protection" is triggered in the last of these event definitions... This is related to:
2) file order
mIRC processes all loaded script files (and thus all event-related scripts matching some event) linear. But we can rarely ensure that "protections" and the like are first in file order... especially if we write addons that someone loads to whatever-scripts-bundle he uses already. First in order - first processed.
I thought the signal would be faster.
Why should it be faster, in the end?
mIRC keeps processing all things "linear", be it an alias or an on signal event.
As far as I understand it (and concuring with JayTea): calling an alias is some kind of "locate alias and if found: execute alias". That is: if the alias is found, done!
On the contrary, sending a signal is more: 1) locating and executing the first on signal event. But then: 2) check for further on signal events.
In addition, if no -n switch is used: mIRC has somehow to "queue" the signal until all other events (and aliases called out of these events) have finished.
And besides the "trigger multiple things out of one signal" advantage, this queue option can help you "speed up" some important parts like protecionts
in a relative way, as you can define:
- which parts should be executed "at once":
by: signal -n or code triggered directly (code or aliases in event definition)
e.g.: protections
- which parts should be executed "later":
by: signal WITHOUT -n
e.g.: stats, counters, auto-messages, titlebar updates, whatever
So what can be done to speed things up?
We could use signal (without -n) for non-critical event-related scripts.
Important things will not be processed faster - but unimportant things will be processed afterwards. 
Some "on !*:JOIN:#: { echo $chan • $nick joins $chan • | haltdef }" is certainly not worh the effort. But there are scripts who are.
Finally, to be honest, I'm rarely exerting this to my own scripts so far - but imho this
*would* be the best method to ensure a good performance of e.g. scripted protections.
There are two other factors one has to account for:
1) number of scripts / event definitions at all
That's plain: The more event definitions mIRC has to get through, the longer it will take till all have been processed. And in the worst case, some "protection" is triggered in the last of these event definitions... This is related to:
2) file order
mIRC processes all loaded script files (and thus all event-related scripts matching some event) linear. But we can rarely ensure that "protections" and the like are first in file order... especially if we write addons that someone loads to whatever-scripts-bundle he uses already. First in order - first processed.
I thought the signal would be faster.
Why should it be faster, in the end?
mIRC keeps processing all things "linear", be it an alias or an on signal event.
As far as I understand it (and concuring with JayTea): calling an alias is some kind of "locate alias and if found: execute alias". That is: if the alias is found, done!
On the contrary, sending a signal is more: 1) locating and executing the first on signal event. But then: 2) check for further on signal events.
In addition, if no -n switch is used: mIRC has somehow to "queue" the signal until all other events (and aliases called out of these events) have finished.
And besides the "trigger multiple things out of one signal" advantage, this queue option can help you "speed up" some important parts like protecionts
in a relative way, as you can define:
- which parts should be executed "at once":
by: signal -n or code triggered directly (code or aliases in event definition)
e.g.: protections
- which parts should be executed "later":
by: signal WITHOUT -n
e.g.: stats, counters, auto-messages, titlebar updates, whatever
So what can be done to speed things up?
We could use signal (without -n) for non-critical event-related scripts.
Important things will not be processed faster - but unimportant things will be processed afterwards. Some "on !*:JOIN:#: { echo $chan • $nick joins $chan • | haltdef }" is certainly not worh the effort. But there are scripts who are.
Finally, to be honest, I'm rarely exerting this to my own scripts so far - but imho this
*would* be the best method to ensure a good performance of e.g. scripted protections.
And then there really isn't much of a way to combine the 2, right?
Most likely you could combine the two scripts - as long as there is no "halt" or "return" command preventing the execution of the one or the other. The one using ^ is likely to haltdef the original text output and display some modified (styled or the like) output - but haltdef is not breaking the script/processing. And I doubt a combination of the two will noticable speed things up
