This isn't anything new, but mIRC really takes a beating whenever there is a lot of channel buffer scrolling (printing) of events or even scripted echos. Printing text is really the slowest thing about mIRC over all other things. (Understandably so.)
I would like to suggest that mIRC keeps a buffer (if it doesn't already) of printing jobs it needs to perform, and if that buffer reaches a certain threshold of backlog, then mIRC can pause re-drawing (painting) updates until the buffer has been emptied.
This would fall under the same theory as using /draw* command's -n switch... to "prevents the display from being updated immediately."
The -n switch prevents the display from being updated immediately. This allows you to make changes to the window in the background and then display the results only when you have finished. You can update the display by using any of the /draw commands with only the window name specified.
Whenever there's a netsplit, and you are in a sizable channel, or multiple sizable channels, mIRC suddenly spikes to 100% cpu and becomes mostly unresponsive until all the QUIT messages have been printed to the respective channels.
This will certainly have to use some self-awareness and introspection by mIRC to realize that a backlog of printing and painting is building up.
