Please be patient. This issue is only about a week old and was filed over the holidays when everyone was out of office.
I took a look at Slow.capx. It seemed OK to me. I have a high-end machine, but I ran a debug build with optimisations disabled which usually more than cancels out the fact it's a high-end machine; despite that it still opened quickly enough (I'd say ~1 second). After a few quick checks I realised the project has around 1000 global variables and most of the work opening the dialog seems to be filling the dropdown list with 1000 entries.
So all this report proves so far is "editing actions using event variables is slow if you have 1000+ variables", which is a really specific situation. It sounds like there's some confusion in this thread over what the problem really is. It seems there may be different cases which are also slow, but unless there is a separate report for those, complete with example projects and reproduction steps such as in this case, I don't have anything to work with. So please try to narrow down each individual case; it seems unlikely that everyone here has a project with 1000 global variables and are repeatedly editing actions with variable parameters.
FYI C2 lazy-creates icons, so the first time you open a dialog it goes and creates thumbnails of the objects in the project. Lazy-creating is important to avoid reaching the 10000 graphics object limit in Windows - it avoids creating icons for things that aren't used or looked at. This would be difficult to change, since if we create icons in advance, it will in some cases unnecessarily use more of the Windows limit. (In C3 we spritesheet icons so, fingers crossed, this should never be a problem ever again in C3.) Anyway, it explains why the first open is sometimes slower, but in a long session only the subsequent opens really matter, so that's what I'd prefer to focus on.