I just used /who as an example, maybe build in something in mirc that help a user so he/she dosent lag so much, i know many people using scripted nick colors for there scripts "im one of them", and now if i use colors for "my nick - oped nicks - voiced nicks", then i can make it without any lag at all, but if i want to grab away users and opers "for that you need to do a /who #channel" it result in a huge lag if you are on more then 2 channels, how ever if mirc it self slows down the /who comand and dosent update the /who as fast as it does now, wouldent that solve the lag problem? atlest a bit? i know it can be scripted, but would be nice if mirc handled it by it self.

I assumed the /who speed depends on how fast the server sends it to you, same as the problem with /list causing lag.

I suppose you could do every 5 seconds or so, /who a*, /who b*, etc.

a que system would be nice. you have that for /op commands and /msg's..

Use smarter scripting if you want to /who several channels and not have it do all the /who's at the same time, thats what timers are for.

I suppose a 'Queue WHO commmands' option in mirc flood settings could be useful, although unless you set the flood settings real tight it will still send several before it triggers flood control and goes into queue.

You could also create your own, send the first and add all the rest to a variable, watch for the raw 315 and have it check if there are more to be done (from the var), if so remove the next from the var and start like a 2 second timer that send the next who command.

I seriously think people do not know about the userhost command. Userhost allows you to retrieve info for 5 users per line. You do 5 lines each interation, you are able to get 25 nicks. Put a 20 or 30 second delay between interations and your set!

/userhost is MUCH MUCH more effecient then /who. And works much better.

True, oper status can be checked with if ($right($gettok($N,1,61),1) == *). I guess the trade off here is less response flood but more outgoing server commands.

Your 'lag' problem basically is that mIRC is unresponsive, well, that is due to execution handled by one processing thread that does the work in the order it received it. It doesnt interrupt it to do something else temporarly.
Since that is a decision in mirc.exe, you cant to anything about it. The only option is to do it yourself, divide the work into chunks, and use a timer to do a chunk every x time units, so mIRC has a breathe between the triggerings to do other things. Of course , to make this sure, you have to make sure a chunk doesnt need more time to process than the interval between two timer triggerings.