Performance Issues

[itssujeeth]

Using the latest version of PAD - It has become extremely slow with high power and CPU consumption.  Debugging is very slow, and sometime the app stops responding for 5-10 seconds.  Any tips to improve performance? I'm developing a web-scraping RPA flow

[itssujeeth]

Adding some more details -  We've been noticing heavy CPU and GPU usage during any debug-executions.  Attached are PE and task-manager views

Red circle shows CPU usage and blue shows GPU usage

This particular flow has 18 sub flows and 79 PAD variables. A similar flow developed and executed using previous preview version of PAD, still runs on preview version faster, with less CPU usage.

[HEATFreight]

Yeah this is killing me! I keep my Dell Optiplex with Windows 10 fully patched and typically have zero performance issue except when things get a little out of hand with hundreds of Chrome tabs or when I try to screen record triple wide 1920x1080 with OBS, yeah ok then I'm gonna hit a performance bottleneck with this machine if I really push it. Running an i7-9700 @ 3.00GHz with 16GB of RAM and 500GB SSD which is less than half full....

Should be able to handle some PAD editing no problem, right? But god almighty is this app laggy! Even after shutting down all programs and rebooting clean, Power Automate Desktop will intermittently run absurdly sluggish, despite the OS behaving normally otherwise. PAD will be choking on a relatively short flow but I can simultaneously fire up 300 Chrome tabs without a hiccup! (usually)... Obviously I try to give PAD the best chance to run smoothly, but it just seems to crap out regardless of what other apps I have open and how excessive my Chrome window+tab count has grown. It seems to be a function mostly of how many actions have been added to a flow and possibly how many edits have been made since last save. I try to keep each flow as simple as possible by breaking up into short subflows and I try to close subflows that I am done editing and I save often! Pretty sure I'm doing all the right stuff. Have even tried increasing the priority for PAD executables in Task Manager - with no noticeable effect. 

PAD requires an internet connection to function at all, so I am wondering if the lag is not a real performance issue with the app running on my machine, but a symptom of poor network latency or dropped requests between my machine and Microsoft's backend for PAD. Like, is it possible that this is simply a network issue and not a performance issue per se?

Anyway, so I have a web automation flow that logs in to a website and accesses eight different pages where it downloads an .xlsx file. Each of the eight file downloads is its own subflow, and there's a subflow to open the automation browser and login as well as a subflow to run a couple scripts to process the Excel files into .csv files. Ten subflows and a Main. Whole thing runs in under 1 minute 50 seconds at its fastest and can take over 3 minutes to complete at worst.

But the real problem is not lag while the flow is running, but slow editing and debugging. Any action at all (scrolling the subflow items, scrolling the actions pane, navigation the subflow dropdown or tab bar, selecting an item, editing an item, moving an item, deleting an item, saving a flow, opening a flow, closing a flow, starting a flow) LITERALLY ANYTHING YOU DO becomes obscenely laggy - both randomly and as a result of reaching sufficient numbers of actions in a single subflow. You can have a flow with a single subflow containing a total of twenty tasks, and this god forsaken software will choke on every mouse movement just because it's Tuesday.

Does not seem to be a strong direct correlation between the editor lagging out and the flow run lagging out. Like even when the editor is completely unusable, the flow may still finish successfully in a reasonable amount of time. I guess I would say there is a direct correlation when editor becomes absurdly laggy, but the flow run does not slow down proportional to the editor lag. Occasionally the lag is sufficient to trip up the flow a bit, but I used short timeout errors that fail to a Go To Label action such that action points in the flow complete successfully despite hiccups. Since I am using automated mouse clicks, there seems to be some correlation between hiccups in the flow run and laggy PAD performance. If my flow were slightly less robust, this would cause it to fail far more often. In fact I would say that the generally sluggish performance of PAD contributed to my experimentation with short timeout errors that fail with Go To Label actions, which successfully sped up my flow and improved its reliability 10 fold. Had PAD not been so sluggish, I might've not even noticed the lack of robust timeout error handling!

anyway, PLEASE INVESTIGATE A FIX ASAP, thanks!!

[yoko2020]

This problem need to be fixed ASAP.

[Anonymous]

Experiencing the same issues here with my work-laptop Dell Precision 3541

i7-9750H 2.60GHz

32GB RAM

500GB SSD

NVIDIA Intel UHD Graphics 630 /w NVIDIA Quadro P620

PAD version: 2.2.20339.22608

Leaving a reply to upvote this issue.

[HEATFreight]

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

[HEATFreight]

Have you tried eliminating all x,y coordinate mouse moves?!?

[HEATFreight]

Tried eliminating all x,y coordinate mouse moves?!?

[Anonymous]

Hi, @HEATFreight! Very interesting. Thanks for the detailed information.

I will have a look at this tomorrow since I am currently going to present the demo-flow tomorrow for my colleagues. I'll try and change it before then and report back to you guys if it has any effect on my side. 🙂

[miketran13]

Thanks a lot for your ideas. It will help me a lot for the coming processes. 

Best regards,

Mike

[joshd111]

I used to have slowness problems, using the December release. Task Manager would show PAD using an holding memory: basically a memory leak. This would lead to great slowness in the ability to edit the flows. 

Since I downloaded the latest install package which is version 2.3.45.21021, the problems have gone away. PAD feels very snappy now. Good work Microsoft!

[Anonymous]

Hello, I am currently working with the latest version of PAD (.69) and I having serious performance issues with simple flows, so it seems that this problem is not solved yet.

[HEATFreight]

@Anonymous What kind of serious performance issues? My flows all work great.

Are your experiencing slow performance with the flow editor or with actual running flows? The more descriptive you can be, the more we may be able to help you!

[Anonymous]

@HEATFreight  thank you for the answer. I was doing a simple flow with 5 subflows and every time I've tried to change a variable value within Set Variable the program crashed. I have work around it deleting that Set Variable action and adding a new one, but this should not be happening I think. I have not heavy processes running in the background and my computer handles other RPA softwares pretty good with no performance issues at all.

[HEATFreight]

@Anonymous hmm, that does sound odd! Are you able to provide screenshots of your subflows?

I have not seen the PAD editor crash at all. I've only seen it lag out really bad. Have not seen any problems for a few months now. Curious to see your flow!

[douglasabreu]

Incrível como tornaram o antigo winautomation um pacote estilizado sem performance. Tento apenas copiar e colar uma ação e isso demora 4 segundos, um absurdo. Eu amava demais o antigo winautomation, uma interface lisa, fluida. A sensação que tenho é que acabaram com um projeto incrível. Ou vocês trabalham para melhorar isso, ou devolvam o winautomation.

[HEATFreight]

@douglasabreu Nunca usei o antigo, mas suspeito que eventualmente consertarão os problemas de desempenho. Uma coisa que percebi é que geralmente leva muito tempo para um gateway PAD baixar o fluxo PAD quando acionado por um fluxo de nuvem, ou a qualquer momento. Eu executo meus fluxos PAD com gatilhos na nuvem e geralmente leva mais tempo para fazer o download do fluxo do que para executá-lo!