Also, not sure why this problem appeared around the time Ps version 24.4.0 was released. Still looks like it might be a bug if that’s the case.
it sure is a strange bug!
I assume there’s a background task (native or from another plugin) that could be affecting the performance.
I tend to wrap my performance sensitive tasks inside a modal function with history suspended.
it’s not ideal but it always performs way better than “naked” code.
hopefully with time PS will get better with queuing tasks and such issues may be solved.
Didn’t have to suspend history @Maher. Using executeAsModal was sufficient in this case. Wouldn’t suspending history create an unnecessary history state on the History panel when one wouldn’t actually be needed to evaluate the actionTree via API or batchPlay?
Thanks all for the great suggestions. I’ll test a few things with the user and report back.
You can suspend history state and then when resuming history set “commit history” to false. Also according to documentation, PS will not create a history step if the document wasn’t modified. https://developer.adobe.com/photoshop/uxp/2022/ps_reference/media/executeasmodal/#history-state-suspension
Good news. Wrapping the loading of actions in executeAsModal fixes the problem. Thanks all for participating and @AnthonyK for the crucial tip. As it turns out my first suspect was right.
The question for me is now when should we wrap the code within executeAsModal. Definetly needed it is only for code that changes the state of Photoshop. So for any task that takes longer and uses more heavy operations?
Maybe people from Adobe can jump in here and give us some tips? @Erin_Finnegan @pklaschka
Is @AnthonyK the only one who understood what I said?
Perhaps there is a modal event that was left open and forgot to close, in the Adobe code that traverses Layers, ActionTree, etc. Or asynchronous processes that need to be await attached but forgot to do so, etc.
executeAsModal has the effect of forcing them to close.
No, I understood it too. But he explicitly mentioned executeAsModal, so I chose his answer as solution … Also your answers were very helpful.
I see. That is a relief.
I usually write most of my sentences via a translation service, so I always worry if it came across correctly.
Apart from the fact that English is not our native language, it is always difficult to communicate only through text. We do not see the expression of the other person. Then, of course, cultural differences come into play, where, for example, something is often offensive that is received quite differently in another culture. Anyway, every participant here has helped me a lot. 
2 Likes
Maybe people from Adobe can jump in here and give us some tips? @Erin_Finnegan @pklaschka
I would defer to @samgannaway, please take a look at this part:
Perhaps there is a modal event that was left open and forgot to close, in the Adobe code that traverses Layers, ActionTree, etc. Or asynchronous processes that need to be await attached but forgot to do so, etc.
executeAsModal has the effect of forcing them to close.
I’m curious, @sttk3 . The batchPlay code you listed. Was it enclosed in executeAsModal when you ran it?
I tried evaluating all the Photoshop actions in the actionTree using batchPlay WITHOUT enclosing it in executeAsModal and found it took the same length of time as the API without executeAsModal, which is to say it was very slow. So, using batchPlay instead of the API didn’t really make a difference in my situation.
However, when I enclosed the batchPlay code in executeAsModal, it was again super fast, just like the API enclosed in executeAsModal.
Bottom line for me is that using batchPlay without executeAsModal to evaluate actionTree offers no real advantage over the API method without executeAsModal. It was enclosing the evaluation method in executeAsModal that was the key to getting a speedy result in both cases.
One thing to be aware of. Without executing as modal it is possible that not your plugin is performing its commands and might be clashing with yours. So if in the middle of your execution somebody else plugin is triggered you can get false performance results.
I uninstalled all other plugins, including mine, that I have installed, and I restarted Photoshop. The problem still persists. Without executeAsModal, evaluation of the actionTree is significantly slower by both DOM API and batchPlay. In other words, it’s very unlikely that another plugin is causing the slow execution of this process.
@AnthonyK My batchPlay code was executed outside of executeAsModal.
However, I observed no difference in speed between DOM and batchPlay in my environment. The existence of modal events that remain open is not proven, just an expectation.