Here's a comparison of the javascript profile for moving an action from one place to another in two projects:
This exact same event structure for testing the movement of an action was used in both projects; the action was moved from the top event to the bottom event once:
Fresh project (Total blocking time: ~0.72 seconds):
Large project - Just opened (Total blocking time: ~0.85 seconds):
Same Large project that's been open for hours (Total blocking time: ~4.3 seconds):
Total blocking time relevance:
The main thread is considered "blocked" any time there's a Long Task—a task that runs on the main thread for more than 50 milliseconds (ms). We say the main thread is "blocked" because the browser cannot interrupt a task that's in progress. So in the event that a user does interact with the page in the middle of a long task, the browser must wait for the task to finish before it can respond.
Whenever I experience this particular slowdown it seems to coincide with the projects memory footprint:
The top row is the project just opened
The bottom row is the same project that's been open for hours
I've mentioned this before in another thread, but the difficulty is identifying what causes this memory footprint to stack up.
I tried to test this by repeatedly using undo / redo, and although it raised the memory footprint about 200 mb it eventually performed what I'd call a garbage dump and the memory footprint normalized: