This is genuinely probably the most effort I've put in to one issue out of the last 1000 bug reports. Right here you have the founder of the company directly trying to help you in an 11 page thread. I'm trying to handle this in a routine fashion, which starts by identifying the root cause. Once we have that, we can consider our options. Sadly sometimes there aren't any immediately obvious options (e.g. if we get hosed by a graphics driver on a particular OS/card combo) and I will say so if I think that is the case. Don't misinterpret that as dismissiveness; this is a routine engineering investigation and that's how it goes sometimes. Honestly, if you think after all this that I just don't care, I am sure nothing I ever do can possibly satisfy you, so why should I keep trying?
Anyways, I'm starting to suspect this really comes down to the Meltdown mitigation patches. A lot of things line up: the timing, the fact it seems to be in Windows code, and the fact the bottleneck on opening these dialogs could well involve a lot of system calls - all it'd need is one or a few system calls in the internal code to add an icon, plus the fact Meltdown's patches have been known to cause major performance regressions to such code, plus the fact the regressions are worse on older CPUs (which explains why our mostly modern systems don't show much of a problem)... it kind of explains everything. Based on this theory I just released a beta of r251 which significantly reduces the number of system calls in this situation, thereby mitigating the performance overhead of the Windows patches for Meltdown. Please give it a spin - make sure you set the icon mode to "Don't show unique icons" to activate the workaround.
If this works, I think it will prove the theory, in which case I must apologise for blaming Microsoft - it would ultimately be Intel's fault Again, I'm not using blame to excuse myself from fixing it - I must point out we just did a beta release specifically to address this, so obviously we're working on it. It's that finding the root cause is essential to know what to do about it. Blame for the root cause, and obligation to fix it, are two separate issues that I think everyone is conflating. If Apple update iOS and totally hammer performance in apps, it's obviously their fault; in an ideal world, they will then fix it. If they don't, out of negligence, lack of caring, or otherwise, then they've screwed over the app developers who then ought to fix it. But in that case I think it's reasonable for the users whose app is now slower to at least have some sympathy for the app developer and co-operate with them. Accusing the app developer of having a broken app is both technically wrong and unnecessarily combative.
Anyways, the next step is: let me know how r251 works out.