A bit of a long read. But, here is some concrete evidence, anecdotal notes, and trial runs about the issue which show roughly 20 hours per project can easily be lost to this bug (so, if you did 5 projects a year, that is roughly 100 hours of your time lost forever due to this issue . . . that is 2 and a half working weeks). It is important to note, these test below are only for the issue of the edit action functionality being slow. It is possible it is related to the other slowdowns experienced, but I could not validate that as it is too time intensive.
TL;DR;: C2 does not run well on W10. Even a small object count (such as sprites) causes slowdowns. The slowdown is overtime as you add more objects, so you don't notice and get "used" to it. By the time you notice, it is too late for your project. Layouts, layers, and global variables do not seem to contribute any notable difference to the general slowdown reported. Several W10 settings/optimizations were attempted with no real difference.
Ran some test with a fresh install of Windows 10, still, need to run a few more to be complete. Essentially going under the assumption *if* the issue is Windows, then there must be a way to make it better. These tests were using the same project each time, same edit each time, fresh reboot each time, and no other applications notably running (one drive shut down, nothing else really has been installed).
Quick Summary: No Windows changes made any real difference so far. However, selecting not to cache icons (within) made the biggest noticeable difference (but not enough of a difference).
Conclusion of the test(s) in this post: No significant change in performance, still at unacceptable levels. (See summary of time lost below)
Overview of time results
When I was done with this batch of testing:
First load (first action change) Icon Full Cache (C2 setting): ~3s
Subsequent loads: ~1.6-1.7s
First load Icon Cache Off (lowest C2 setting): ~1.7s
Subsequent loads: ~1.5s
Note: By load, I mean editing an action. The time it takes from clicking the action, until the dialog pops open.
Quick estimation of time lost in W10 versus W7:
Assume 5,000 events.
Each event has on average 10 actions.
Just to create these 50,000 actions is (best case): 75,000s lost (1,250 minutes or 20.83 hours)
If you do smaller projects, estimate accordingly (500 events means ~2 hours lost).
This is a rough estimation and in my opinion best case scenario. In reality, it is much worse because more than just adding/editing actions are affected as seen in dop2000 video and others. This is also ignoring the slowdown overtime issue. It also ignores edits to actions (aka you wrote "perfect" code and ran into zero errors).
Test run so far:
Indexing completely shut off. No difference.
All background apps, telemetry, and so forth shut down. No difference.
Display settings set to best performance. No difference.
C2 in Compatability mode: No difference.
C2 with higher affinity/process power: No difference.
C2 with elevated priviledges: No difference.
Note: I did not test for extended use in these scenarios. This means, how C2 slows down while the computer is on longer. This type of test would be too intensive for all of the scenarios I am running.
Once time allows, I have several other tests to run (such as caching size, paging, and some other test which I have run already but am now collecting concrete data on).
I wanted to see at what point did the project become fast again. I did a series of "reverse coding" or stripping down. Here is the results:
Deleted all global variables: No difference.
Deleted all sounds: No difference.
Deleted all but 1 layout and event sheets: No difference.
Deleted Sprites: This is where it got interesting. Deleting the first couple, took forever. You could see the Object Properties scan through every object (or so it seems). It took a couple seconds (5 seconds for the first batch) to delete each one (once less objects existed, it was near instant). It was not until I had a couple left did the editor become more responsive. By the time I deleted every object, the window pops after 0.2s (visibly, it is instant). A difference of ~1.5s. The dialog pops so fast, I cannot time it accurately.
This confirms what others have mentioned, about object count is the killer.
The project did not have that many objects to start with. Even at ~30 objects, the editor was terribly slow. (speed is directly correlated with number of objects/sprites as shown in this thread throughout numerous examples).
My question or thought as a result of this is , why would this slow down updating a variable in an action? What is C2 doing that is taking so long, if it is drawing icons as suggested in another post, something does not add up. Does C2 redraw the whole window, and all objects, when opening the edit action pane?
What I found from the above "tear down":
1) The editor for some reason goes through all objects below the object being deleted. I can visibly see the objects underneath being processed. If I have 10 objects, 1-10. If I deleted #1, I see 2-10 in the object info window. If I delete 9 I only see 10 get processed and it is incredibly faster than deleted #1. This means, if you had 100 objects, deleting object 1 will cause C2 to spin gears while you wait. This is not part of the bug (unless they are related, but I have no way of knowing), but an interesting finding.
2) More objects causes the project to go slower. Slow downs seem to be seen pretty easily. The slowdown is rapid and hard. When deleted the objects one by one, the editor got faster and faster.
3) Number of variables, does not seem to have any affect. Number of layouts either. Not in this test atleast.
4) Having Properties Bar, Project Bar, Layer Bar, Object bar enabled or disabled had no difference.
5) Having dozens of layouts + event sheets open versus just 1, made no difference.
6) Based on my tear down, if you hit this issue it is already too late. The object count is super low to start having issues, and its compounds in itself terribly. Re-use sprites as much as you can, but unfortunately, it seems even optimized projects with low object counts can hit this issue. I cannot think of a reasonable workaround at the moment, as any full-blown mobile app/game would reasonably go over this threshold of the object count. Since the issue is slowly rising, you get used to it and explains why so many people did not realize it was an issue until they compared between two projects, or compared W7 vs W10.
7) I tried moving objects into folders, this had no effect on action dialog time in the end. However, it did trigger the "slowdown overtime" issue. The dialogs took 4x as long to pop after moving a bunch of objects into folders. Upon a system restart, the times went back down. For example 1.5s load. Move a bunch of objects to folders. 5-6s load time for dialogs. Restart, back to 1.5s. This is unconfirmed if reproducible. If I have time I shall try this a few more times, it just takes forever to repeat since moving objects is crazy slow to do.
8) The issue is not resource bound. I tried this while mining on both CPU and GPU. Similar times were experienced (This was near constant 100% load on my CPU and GPU).