Thanks for your bug report and the script to reproduce the issue.
I was able to track this issue to Item 11 in beta.txt, the change in the subclassing method. I changed the subclassing method from SetWindowLongPtr() to SetWindowSubClass() as it had been on my to-do list for some time as a more robust of method of subclassing.
I was able to pinpoint the slowdown, using a profiler, to the DefSubclassProc() API call. DefSubClassProc() simply tells the window procedure to call the next handler in the window chain. As far as I can tell, this API seems to be slower than the older subclass method that uses CallWindowProc() to call the next handler. The SetWindowSubClass() / DefSubClassProc() APIs are provided by Comctl32.dll, as opposed to User32.dll. I have no idea how Comctl32.dll implements subclassing - it is meant to be more robust and maintains an internal list of subclassed window procedures along with unique ids to identify all subclass instances. Windows in mIRC are heavily subclassed - so every window that is created has multiple subclasses relating to the display area, editbox, listbox, scrollbar, and so on to customize behaviour. When a hundred windows are opened, this results in a large number of unique subclass instances. Another issue that the profiler picked up is that the Comctl32.dll subclass method seems to use GetProp() internally, possibly to track windows, which is slower than GetWindowLongPtr(). Unfortunately, that is all the profiler could pick up.
I have reverted the use of the new subclass method for the treebar and this has resolved the issue. At this point, I am tempted to revert the new subclass method for all features but I am going to do a little more testing to see if it is necessary. This change will be in the next beta.
