I figured it out!
TL;DR: No x,y coordinate mouse movements!
My biggest problem was that I was using too many commands to move the mouse to an x,y coordinate to send a click, and I was using timeout errors that were looping back to labels to reiterate each command until no errors.
BAD!! Who knows how many times each of those naked clicks was looping while my entire PC was choking on the PAD Flow. I was trying to get lucky with timing instead of hard coding a rigorous sequential logic from step by step inputs and web page responses - WITHOUT MISSING ANY STEPS, like teaching a blind alien how to make a ham sandwich.
Once I realized the best function to send a click directly to the correct UI element (and this takes some experimentation with each specific use-case since there are several different ways to click an element), performance shot through the roof, both in terms of flow runtime as well as editor lag. I got rid of every single one of the timeout errors which I had previously thought were so crucial. Used WAIT FOR WINDOW and WAIT FOR WINDOW CONTENT (text) actions when I simply needed to wait on a web page to load or a save dialogue to open. My use case was tricky because each of the 8 distinct webpages required one MOVE MOUSE (x,y) action and a SEND MOUSE CLICK action. I was not having much luck with MOVE MOUSE TO IMAGE or CLICK UI ELEMENT IN WINDOW for this particular download button. It's just 20x20 pixel Excel logo that I have to click, but CLICK DOWLOAD LINK ON WEB PAGE does not work for this button. What I was doing previously was moving to the absolute coordinate and sending a click. It's important to have an WAIT FOR IMAGE (in foreground window) action before the move and click! You can use a label and a timeout error with return to label on timeout, but it can be extremely tricky to get the timing right, and seems nearly impossible to perfect for 100% success rate, but I think my solution has solved this...
If you do use mouse movements, USE AS FEW MOVE MOUSE ACTIONS AS POSSIBLE. YOU ALMOST NEVER NEED TO "MOVE" THE MOUSE. Often times you can simply use a series of WAIT FOR ELEMENT actions with CLICK UI ELEMENT IN WINDOW actions but no MOVE MOUSE or SEND MOUSE CLICK or SEND KEYS actions if you can avoid them.
The actions in >Mouse and keyboard section are somewhat less reliable or more finnicky in my experience, but most importantly you get into trouble with terrible lag. By removing all x,y mouse movements, I completely and totally abated the extreme lag in my semi-complex Flow which contains 11-subflows with 10 to 14 actions each. Used to be 20+ actions per subflow when moving mouse via x,y coordinates. I was troubleshooting hiccups in the flow where a click would misfire while a UI element wasn't ready to be clicked yet, and I began eliminating x,y mouse movements as I began to see how much more reliably the CLICK UI ELEMENT action was performing. But there was always one click that I could not get to work without an x,y mouse move....
This flow downloads 8 .xlsx files from 8 distinct URLs within the same web session, then converts them to .csv and moves them to a fileshare, and finishes by closing PAD Console window. And I launch it with a single click of a macro button on my Elgato Stream Deck. One click and about 1 minute 40 seconds later the entire process will be complete if it's running fast, and over 2 minutes would be slow at this point (compared to 3 or 4 minutes with frequent hangs in my previous builds). Not trying to run asynchronously yet, but there may be room for improvement if I try to do this in multiple tabs (can't use automation browser in that case), or multiple automation browser windows. Or the subflow logic could be further parameterized and reduced in size by adding some more small subflows to handle tasks I repeat in the existing 8 main subflows that I have now -each of which essentially repeats the same tasks for a different webpage- but that would require some abstract logic that my brain does not want to contemplate at the present time, thus I keep the structure I have now until further optimization becomes prudent. Anything to reduce total number of actions can improve editor performance, but it seems nothing nearly as much as replacing x,y mouse movements.
I got rid of x,y mouse moves and "naked" mouse clicks where you just hope and pray that the correct element is under the mouse when it gets to x,y, and that has reduced the complexity and length of my subflows significantly while allowing me to reach near perfection with flow finishing successfully. If you can avoid it, don't just send a click into the ether and hope it finds an element to land on! Without using any timeout errors at all, I use the following logic (pseudocode):
>WAIT FOR IMAGE (make sure to add the UI element with the image selector tool that lets you draw over the image at precise pixel locations. I had great success when I precisely selected the 20x20 pixel Excel button as an image element and waited for it to appear in foreground window)
>MOVE MOUSE TO IMAGE (and send click after 1 second in foreground window) ***THIS WORKED WHEN CLICK UI ELEMENT WOULD NOT!!!***
>WAIT FOR WINDOW ("File Download" to open)
>WAIT FOR WINDOW CONTENT ("Save" to appear in window "File Download")
>CLICK UI ELEMENT IN WINDOW (button "Save")
>WAIT FOR WINDOW CONTENT (UI element window "File Download" to disappear in window)
> WAIT FOR WINDOW (window "Save As" to open)
>POPULATE TEXT FIELD IN WINDOW (Edit 'File Name:' with 'text.xlsx') ***WARNING*** avoid doing this if possible, letting it save with the default name and force overwrite existing file is faster than changing default name
>CLICK UI ELEMENT IN WINDOW (Button "Save")
>WAIT FOR WINDOW ("Confirm Save As" to open)
>WAIT FOR WINDOW CONTENT ("Yes" to appear in window "Confirm Save As")
>CLICK UI ELEMENT IN WINDOW (Button "Yes")
My flow runs wayyy faster than before and the editor is totally usable again! Difference is like night and day.
Anway here's some more tl;dr:
GET RID OF YOUR X,Y COORDINATE MOUSE MOVEMENTS! Each one of them adds substantial lag to both the editor and runtime while making it unstable, with more hangs and failures.
GET RID OF ALL YOUR TIMEOUT ERRORS! ...almost all of them anyway.
Use WAIT FOR _______ actions and make sure your clicks are direct to a UI element or precisely-pixel-matched image if possible, i.e. NO NAKED CLICKS!
Try to SHIFT+LCLICK on the outer (largest) window element when you are adding a new element in WAIT FOR WINDOW action, and experiment with different red boxes (highlighted element) in the other WAIT FOR CONTENT actions. Generally WAIT actions are more successful when contingent on a whole window element - like CONFIRM SAVE AS or FILE DOWNLOAD or GOOGLE CHROME or FILE EXPLORER - so I use WAIT FOR WINDOW followed by WAIT FOR WINDOW CONTENT then CLICK UI ELEMENT IN WINDOW. With this sequence, no timeout is needed.
NO >Mouse and Keyboard ACTIONS! Reduce flows and subflows to minimum possible number of naked clicks or x,y movements that get you desired result most of the time.
EDIT: you might consider using some clever timeout errors... For actions that require timeout errors, the really crucial thing is to set the "On error" logic to "retry action if an error occurs" or >Continue flow run >Repeat action (I'm not really sure of the nuance here, or which is better...need to experiment more if I continue to see occasional hangs).
EDIT2: This is a jankyass website I'm working with, helps to increase click delay on my MOVE MOUSE TO IMAGE (and click)
Use timeout errors only for specific edge cases, otherwise let PAD figure it out using the WAIT WAIT CLICK sequence to ensure UI elements are in place before clicks are sent. When you do it this way, PAD seems to ensure the click lands on a loaded UI element instead of disappearing into the void and looping endlessly out of sync. I use timeout errors only for the MOVE MOUSE TO IMAGE (and send left click after 1 second) action, which is the only way that I have found consistent success in clicking the weird Excel .xlsx download button on this website. If the site is slow, my 1 second click delay and 5 second timeout error are insufficient for the 3 largest files to be fetched and loaded into this company's web portal. Tweaking the click delay is crucial. The timeout error should be several click delays long such that you have a factor of safety over the expected page load delay or file retrieval delay in this case. My flow is still not perfect because of the way the MOVE MOUSE TO IMAGE (and send click) action works. Seems that slow page loads can still trip it up here (as I said, I need to tweak the "On error" logic. If you don't have a sequence that eliminates all >Mouse and keyboard CLICK / MOVE / SEND KEY actions, then you will probably be stuck with a logic that proves fragile in the face of occasionally slow page loads, or your flow will have to run slowly to be patient with the page loads. These actions have a tendency to break out of the error loop in a discontinuous manner, and it's difficult to efficiently solve this. I have still not seen absolute perfection in flow execution as a result of the different nuance to the flow logic of click actions that parameterize by UI element (reliable) vs. any >Mouse and keyboard action (unreliable), but with everything I've learned, I am mitigating the major issues and getting excellent results!
Seems that parameterizing the target of your mouse click as a specific UI element is the best way to get a snappy flow with zero failures and no need for timeout errors. Of course, your use-case could be different than mine. You may be happy to help the flow out with an occasional human-controlled click here and there, but I wanted to fix whatever was making my clicks misfire, and getting rid of the "naked click" has made all the difference! I'm a PAD believer again. I had become quite frustrated due to the lag, but that is essentially nonexistent now and my flow is robust and reliable. Super thrilled to reach this point! Microsoft kicks ass!
EDIT: PAD is still a really laggy app lol
EDIT2: i hope it doesn't matter that my flow closes the PAD Console lol
EDIT3: get a Stream Deck
