|
Joined: Jan 2004
Posts: 509
Fjord artisan
|
OP
Fjord artisan
Joined: Jan 2004
Posts: 509 |
Is it always faster to call an alias in a remote? Example.
if (this) {
/dothisalias
}
if (that) {
/dothatalias
}
Where. alias dothisalias {
is a bunch of if-elseif-else statements
}
2.And then, would you rather call in an alias, or use signals? I read a tutorial on on signals and I don't see how that or calling in aliases are faster, as mIRC will have to perform them all anyways. 3.Also, for a flood script, which is faster. On text or on ^:Text? I noticed when there's flooding, my mIRC temporarily freezes and the Ctrl Breaks return my 2 major text events, 1's on text and the other is on ^ text. My current flood-kicking script is on text, but I read a flood script which uses ^. It basically increases a variable for $nick.$chan.etc and ban kicks if the variable researches a number. And then there really isn't much of a way to combine the 2, right? 4.Which is faster. if (a) && (b) { do this } if (c) && (d) { do that } Basically for any event all if statements have to be called. The above should be faster than.. if (a) && (b) && (!c) && (!d) { I'm guessing there's a cutoff point, because you could go all the way to... if (y) && (z), right? 5.I was trying to help someone, but couldn't find the most efficient way. An on mode event that reverses everything someone does. Example: someone sets mode: +a-b You set mode: -a+b I have.
on *:mode:#: {
if ($nick == ) {
/mode $chan $replace($1-,+,-,-,+)
}
}
That just means +o-o becomes -o-o. And using $replace($1-,-,+,+,-) just makes +o-o +o+o, etc. So I used something like: if (+ isin $1-) { /mode $chan $replace($1-,+,-) } if (- isin $1-) { /mode $chan $replace($1-,-,+) } Therefore. Someone sets mode +abc-def You sets mode -abc You sets mode +def Of course, this takes double lines, double flood. Anyone know a way to make it work in 1 line? Thanks. -Neal.
|
|
|
|
Joined: Oct 2004
Posts: 8,330
Hoopy frood
|
Hoopy frood
Joined: Oct 2004
Posts: 8,330 |
For all speed related questions, it is always better for you to test it yourself. Asking here just means *someone* has to test it, so you might as well do it yourself to save others from doing what you can do. Besides that, depending on what scripts you are running, the speed and memory of your computer, what other programs you're running, etc... the results may be different for you than for someone else. Testing speed is really easy. Here's a small example.
alias remote_speed {
var %ticks = $ticks, %cnt = 1
while (%cnt <= 20000) {
var %test = 1
inc %cnt
}
echo -a Speed (ms): $calc($ticks - %ticks)
}
Then in aliases:
alias_speed {
var %ticks = $ticks, %cnt = 1
while (%cnt <= 20000) {
var %test = 1
inc %cnt
}
echo -a Speed (ms): $calc($ticks - %ticks)
}
You can adjust the 20000 to another number if you want. A higher number gives more accurate results, but takes longer. Note that you can take the Speed out of (ms) by using $duration, but I personally think it is easier to see differences this way. For any other speed difference questions, just put whatever you're testing *inside* the loop in place of the "var %test = 1". If you're using different kinds of events, you still do the same basic thing... but put the code into those events and test.
Invision Support #Invision on irc.irchighway.net
|
|
|
|
Joined: Oct 2004
Posts: 8,330
Hoopy frood
|
Hoopy frood
Joined: Oct 2004
Posts: 8,330 |
For your last question... /help $replacex
Invision Support #Invision on irc.irchighway.net
|
|
|
|
Joined: May 2007
Posts: 89
Babel fish
|
Babel fish
Joined: May 2007
Posts: 89 |
Is it always faster to call an alias in a remote? Imho, it depends greatly on how the alias being called is coded. And also on why it has to be called. There are many cases where aliases are not needed even though the programmer wants to neaten the code. As a matter of fact, it is generally recommended to use a subalias whenever some statements in the source repeat themselves.This will then save space and therefore, the interpreter's parser would be quicker (only if things are well written though :p ). 2.And then, would you rather call in an alias, or use signals? The advantage of the "on signal" event is stated in the help file itself. Signals are a simple way of triggering signal events in multiple scripts at the same time. Whereas, simple aliases can't be called in multiple scripts at the same time. Furthermore, By default the signal is triggered after all current scripts have finished executing. You can however use -n to make the script trigger immediately. This statement clearly shows that in some particular cases, signal events are better to use than any other method. For example, in a protection script, you could just use a signal with the -n switch. This will make your protection script react before all other scripts. 3.Also, for a flood script, which is faster.
On text or on ^:Text?
I noticed when there's flooding, my mIRC temporarily freezes and the Ctrl Breaks return my 2 major text events, 1's on text and the other is on ^ text.
My current flood-kicking script is on text, but I read a flood script which uses ^. It basically increases a variable for $nick.$chan.etc and ban kicks if the variable researches a number.
And then there really isn't much of a way to combine the 2, right? If your mIRC freezes when there is flooding, it may be normal. Normal, because it was a massive flood where all the better and fastest protection scripts would freeze. Not normal, because the protection script was badly written. The basic usage of the ^ prefix is to halt mIRC's default displayed texts for particular events. It may gain some milliseconds if correctly used but it won't be significant enough during massive floods. The protection script you read (the one using ^) may only be better as it may have been written better. Prefer hash tables for protection scripts. They are basically quicker. But I think I've read something on variable being faster than hash tables in some cases. Once more, the way some function reacts (rapidity, reliability) stand only on the way it was written. 4.Which is faster. if (a) && (b) { do this } if (c) && (d) { do that }
Basically for any event all if statements have to be called.
If you don't want all the 'Ifs' to be executed, then use 'ElseIf'. The above should be faster than..
if (a) && (b) && (!c) && (!d) {
I'm guessing there's a cutoff point, because you could go all the way to... if (y) && (z), right? It won't be faster because you use && everywhere. This means that for the "if" to be validated, it has to go through all the conditions. It won't be validated only and only if some conditions are false. The first false condition in a "if" statement containing only '&&s' is the cutoff point. 5. I've found only this solution (for now) to reverse all the modes put on a channel. Basically, the function 'RevMode' parses the <string> $1- for each character looking for a '-' or a '+' and then replaces the latters accordingly until the end of the <string>. on *:mode:#:{ MODE $chan $RevMode($1-) }
Alias RevMode {
Var %m = $1- , %i = 1 , %k , %z
While $mid(%m,%i,1) {
Var %k = $v1
Var %z = %z $+ $iif((%k == -),+,$iif((%k == +),-,%k))
Inc %i
}
Return %z
} If ever I find a way ( or maybe someone else will find it), then there'll surely be a new post following this one. Cordialement
tropnul
|
|
|
|
Joined: May 2007
Posts: 89
Babel fish
|
Babel fish
Joined: May 2007
Posts: 89 |
Alright, i've recoded some part of $replacex(). I should have read the help file once more I think. :s
tropnul
|
|
|
|
Joined: Jan 2004
Posts: 509
Fjord artisan
|
OP
Fjord artisan
Joined: Jan 2004
Posts: 509 |
Signals are a simple way of triggering signal events in multiple scripts at the same time. Whereas, simple aliases can't be called in multiple scripts at the same time. The way I understand it, mIRC doesn't do 2 things at the same time. It does 1 right after the other. So let's talk about multiple scripts. If I have a /dothisalias that triggers for an on text, join, and quit event, and all 3 happened, then mIRC will perform the alias 3 times in a row, in the order the server sent in /debug @debug. So isn't this the way mIRC performs an alias in multiple scripts? Is this what you meant by multiple scripts? How does the signals make the advantage? By default the signal is triggered after all current scripts have finished executing. You can however use -n to make the script trigger immediately. Okay, so this is a way to get the more important stuff done first. I see that as a benefit. But so using the -n switch is pretty much the same as calling an alias? This statement clearly shows that in some particular cases, signal events are better to use than any other method.
For example, in a protection script, you could just use a signal with the -n switch. This will make your protection script react before all other scripts. Okay, seems like signals are all about order. -Neal.
|
|
|
|
Joined: Oct 2007
Posts: 92
Babel fish
|
Babel fish
Joined: Oct 2007
Posts: 92 |
/signal [-n] <name> [parameters] That's what the help file said about on signal i always used this but what does parameters do?
|
|
|
|
Joined: Jan 2004
Posts: 509
Fjord artisan
|
OP
Fjord artisan
Joined: Jan 2004
Posts: 509 |
/signal [-n] <name> [parameters] That's what the help file said about on signal i always used this but what does parameters do? Take a look at the below tutorial: http://www.mircscripts.org/showdoc.php?type=tutorial&id=1305As per the script with the siganl, I don't see how that is any way faster.. -Neal.
|
|
|
|
Joined: Dec 2002
Posts: 2,962
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 2,962 |
The additional parameters passed make up the $1- in the signal events.
Spelling mistakes, grammatical errors, and stupid comments are intentional.
|
|
|
|
Joined: Dec 2002
Posts: 2,962
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 2,962 |
The 'multiple scripts' aspect of signals is that multiple scripts can trigger from a single signal without that originating script needing to to know about all the receiving scripts at the time it's written.
For instance if I had a script that allowed mIRC to send and receive video messages I could have that script do /signal vidstreamstart nickname on creation of a video link, and /signal vidstreamend nickname upon closing. Then, I could have any number of other scripts use on *:signal:vidstream*:do_stuff to trigger additional behaviour in mIRC that is beyond the scope of the original video streaming script (for instance I might later decide it's useful to stop music playing on video start, or to set myself away/back on IRC when opening/closing video links).
There's no simple way to do that with aliases - I'd need to know all the scripts that are going to be called when I wrote the original video streaming script.
Spelling mistakes, grammatical errors, and stupid comments are intentional.
|
|
|
|
Joined: May 2007
Posts: 89
Babel fish
|
Babel fish
Joined: May 2007
Posts: 89 |
Imho, events are parsed by the mIRC's interpreter first. Then if some alias is called in an event, it will parse the file to execute it. If that is the case, then signal events are 'faster' than calling aliases to do the same work. I'm not sure if that's right as I'm no expert of mIRC's internals. Maybe someone could give us more information on this issue about what is parsed first by the interpreter. However, there could be another version. Maybe everything is parsed in one go. Then events, aliases, menus, etc.. are all indexed in a hash table to be easily and rapidly called later on when needed. This method has an advantage over the last one but still has a disadvantage for speed concerns. Because if there are more aliases than events for example, then the parser will take some time to parse everything before execution starts. I would personally prefer it to parse all events first, then parse everything else. As a matter of fact, aliases can only be called in events in mIRC, except in popups (by the user) or through the editing line (by the user also). This then supports my first idea. But once more, I can't prove all that. Just some thoughts. Cordialement
tropnul
|
|
|
|
Joined: Feb 2006
Posts: 546
Fjord artisan
|
Fjord artisan
Joined: Feb 2006
Posts: 546 |
just focusing on this one difference between a signal (-n) and an alias, once the signal event has ended, mirc continues to look for matching signal events in other files. but once an alias is found it stops there. can't think of any reason why using signals would be quicker than using aliases :p but like i always say, when you're dealing with these negligible differences in speed use what is suitable to your task
"The only excuse for making a useless script is that one admires it intensely" - Oscar Wilde
|
|
|
|
Joined: Jan 2007
Posts: 1,156
Hoopy frood
|
Hoopy frood
Joined: Jan 2007
Posts: 1,156 |
first try: time to process using alias: 1469 time to process using signal -n: 2750 second try: time to process using alias: 1437 time to process using signal -n: 2844 I had the alias and the signal inc the loop variable and this is the result I got. Aliases are twice as fast, go figure. I thought the signal would be faster.
|
|
|
|
Joined: Nov 2006
Posts: 1,559
Hoopy frood
|
Hoopy frood
Joined: Nov 2006
Posts: 1,559 |
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
Last edited by Horstl; 08/12/07 03:29 AM.
|
|
|
|
Joined: Aug 2005
Posts: 1,052
Hoopy frood
|
Hoopy frood
Joined: Aug 2005
Posts: 1,052 |
*Thinks that Horstl needs to nap his fingers they must be blistering.
if $reality > $fiction { set %sanity Sane }
Else { echo -a *voices* }
|
|
|
|
Joined: Jan 2004
Posts: 162
Vogon poet
|
Vogon poet
Joined: Jan 2004
Posts: 162 |
Does mIRC maintain a buffer or so with the scriptfile, event description and memory pointer (the triggering conditions) of all events, so it only has to go through this list to know which events in which files should be triggered? That would act like an index so decrease the amount data to go through. And maybe something similar for aliases?
Last edited by RRX; 08/12/07 06:32 AM.
|
|
|
|
Joined: Nov 2006
Posts: 1,559
Hoopy frood
|
Hoopy frood
Joined: Nov 2006
Posts: 1,559 |
dunno why it doublicated, and now it's to late to edit
|
|
|
|
Joined: Jan 2007
Posts: 1,156
Hoopy frood
|
Hoopy frood
Joined: Jan 2007
Posts: 1,156 |
lol @doublicated. Thanks horstl.
Does mIRC not keep a list of events and aliases? I would think it wouldn't search through every file for a specific event but check the list of stored events or aliases. I have no idea.
EDIT: Oh, sorry I guess RRX asked the same q.
Last edited by DJ_Sol; 09/12/07 07:27 AM.
|
|
|
|
Joined: Oct 2004
Posts: 8,330
Hoopy frood
|
Hoopy frood
Joined: Oct 2004
Posts: 8,330 |
Yes, I believe the list of aliases are stored in memory (as you can see, the View menu in the Aliases tab lists them).
Invision Support #Invision on irc.irchighway.net
|
|
|
|
Joined: Jan 2004
Posts: 162
Vogon poet
|
Vogon poet
Joined: Jan 2004
Posts: 162 |
Yes, I believe the list of aliases are stored in memory (as you can see, the View menu in the Aliases tab lists them). That lists the alias definition's diskfiles, not all aliases (Remote) as such. I ment: an index, a table in RAM, with the names of all aliases and their 'memory' addresses, so mIRC doesn't have to dwell through all the running code but has just to jump to the in-the-index specified offset, abit similar to the segment descriptors in OS'es memory management. If this is true it would imply that as soon as mirc starts running edited code it has to re-make that index. If mIRC does do this, then using ! for speed improvement delivers little gain, if it doesn't do it, then it may deliver substantial gains, depending on several factors, such as position of the alias (load order and begin or end of the file), at expense of an extra char for every native mirc command (the !). Also, if it doesn't keep an index, or maybe even regardless this, I'd say it would be worthwhile to have, as scripter/user, some control over mircs parser, for ex, a setting/script command to set native commands as default, so that you don't need to use the ! everywhere to force mirc to NOT search. In that case you could start a piece of code with (ex) "native on", from which point it directly uses native commands (and doesnt look in aliases/remote), until it finds a "native off". Abit similar to how /scid and /scon work, and maybe also like those, only for the currently running code, ie, if alias A calls alias B and alias B switches it (too), alias A isn't affected.
|
|
|
|
|