debug/socket scripting or event scripting

i have read some article about debug identifier and socket scripts a lot better / faster than event scripts, anyone know the right answer or any comments ?

I'm confused about the question. Actually, I don't really see one at all. Are you asking if the statement you made is true? Socket scripts are implemented *using* event scripts, since sockets use events (ON SOCKOPEN, ON SOCKCLOSE). If you are talking about implementing a socket script that connects to IRC in order to replace events like ON TEXT, the answer is: no, they are neither better nor faster than regular events. Quite the opposite, actually... implementing a socketbot to connect to IRC will be much more complicated, error prone, and less efficient than letting mIRC do what it is made to do: handle an IRC connection. Using /debug is just as flawed, for the same reasons.

Let me try detail with little code,

Debug way;

Code:

alias debug_test {
  tokenize 32 $1- 
  if (($1 = <- && $3 = PRIVMSG) && ($4 ischan)) {
    var %nick = $right($token($2,1,33),-1)
    var %text = $right($5-,-1)
    if (testing isin %text) {
      ban -k $4 %nick 2 banned.
    }
  }
}
/debug -i debug_test

The -i switch calls the specified identifier before a debug line is logged. The return value of the identifier is used as the debug line.

Event way;

Code:

on *:text:testing:#:{ ban -k $chan $nick 2 banned. }

Right it looks event shorter actually, but im asking is the debug way would improve the code to better or faster ?

It's already been stated that it will not be better or faster.

In theory it should be slightly faster as it triggers before mirc processes the event (hence why you can use debug to halt the version reply), but the difference will be negligible.

That's not "faster", that's just "before". Remember, mIRC isn't multi-threaded, so the fact that /debug -i triggers before the event isn't the result of a race condition, it's the result of mIRC running debug prior to event processing; if you don't have /debug, event processing will be called at the same time debug would have been. But even if there was some efficiency boost in the calling, you will lose all that overhead when you start having to parse all the details out of the line manually with $gettok or /tokenize.

Well I would presume mirc makes the check to see if debug mode is on before it looks for any events, so it will still be faster, although I guess the difference is negligible now that I think about it.

Not only negligible, but non-existent. Even if mIRC chooses to run /debug, it's still parsing the conditional-- you could represent it by the pseudocode:

Code:

if (debugEnabled()) runDebug();
runEvents();

Even if debugEnabled() is slow (it's probably not even a function, but just a BOOL or int value), both code paths execute the function, so it's still: <delay> <runDebug> or <delay> <runEvents>.

The only case where it would actually be slower would be if you had /debug -i on for something else, in which case mIRC would process as: <delay> <runDebug> <runEvents>. But since you're using /debug already, you probably don't want to replace it with event handling code anyway.