15.3 Profile Execution: Finding Performance Bottlenecks in Studio
Key Takeaways
Profile Execution is turned on from the Debug ribbon and shows per-activity times in the Profiling panel after a run or debug session.
Container durations include their child activities; with no file selected, the total is the sum of top-level durations excluding Invoke Workflow activities.
Execution Details show the number of executions and the average, minimum, and maximum duration.
Profiling sessions are saved locally in the ProfiledRuns folder and can be imported later for comparison, with Focus disabled.
Common findings are full UI timeouts on absent elements, nested loops, repeated asset reads, and fixed delays.
15.3 Profile Execution: Finding Performance Bottlenecks in Studio
Core Concept: The exam description lists profile execution under Debugging. Profile Execution measures how long each activity takes while you run or debug a workflow, so you can find the steps that slow an automation down instead of only looking at its total duration.
Using Profile Execution
- Turn on Profile Execution on the Debug ribbon.
- Run or debug the file with representative data.
- Open the Profiling panel. It lists the workflow's activities with their execution times and each activity's cumulative share of the execution time.
- Select an activity to see the Execution Details at the bottom of the panel: the number of executions and statistics such as the average, minimum, and maximum duration.
Context menu actions
| Action | Use |
|---|---|
| Open | Right-click the parent file to open that workflow |
| Focus | Center the designer on the selected activity |
| Search | Find specific activities in the results |
| Expand All / Collapse All | Show or hide the activity tree |
How the Durations Are Calculated
- Execution duration runs from the start of a workflow's first activity to the end of its last activity. For a file with a top-level Sequence, the Sequence shows the total time taken by all its activities.
- A container's time therefore includes its children. Expand the tree to find the leaf activity that actually consumes the time.
- When no workflow file is selected, the total shown is the sum of all top-level durations, excluding Invoke Workflow activities.
- When several runs or test cases invoke the same file, Profile Execution groups the executions of that invoked file. The total may then differ from the real elapsed time, but the grouping produces statistics that reveal occasional slowdowns.
Considerations
- Debugging adds overhead. Profiling data collected while debugging can differ from data collected while running the file. Profile a run when you want production-like numbers.
- Sessions are saved in
C:\Users\username\AppData\Local\UiPath\ProfiledRuns. - Import profiling sessions to review previous runs and compare them with the current one. Focus is disabled for imported sessions.
Typical Bottlenecks and Fixes
| What the profile shows | Likely cause | Fix |
|---|---|---|
| A UI check such as Check App State or Element Exists takes about 30 seconds whenever the element is absent | The activity waits for its full timeout (30 seconds by default for UI activities) | Set a realistic timeout for optional elements, or use Check App State with appear and disappear branches |
| An Assign or If inside a loop has a very high execution count | Nested loops over two tables | Use a LINQ join, a Dictionary lookup built once, or Join Data Table |
| Get Asset or Get Credential appears once per transaction | Assets read inside the transaction loop | Read them once in Initialization and keep them in the Config dictionary |
| Delay activities take a large share | Fixed waits used for synchronization | Replace with activities that wait for a UI state, such as Check App State |
| Excel activities run thousands of times | Cell-by-cell reading or writing | Read or write ranges into a DataTable |
| An Invoke Workflow File is slow on every call | The invoked workflow reopens an application each time | Open the application once and pass what is needed as arguments |
Worked Example
A performer takes eight minutes for 50 invoices. The developer runs one batch with Profile Execution on.
- The top-level Process sequence accounts for most of the time, as expected.
- Expanding it shows a Check App State for a "Duplicate invoice" dialog taking about 30 seconds on most transactions. The Execution Details show 50 executions with a similar average, which means the wait happens every time the dialog does not appear.
- The developer lowers that activity's timeout to 3 seconds, because the dialog appears immediately when it appears at all.
- A Get Credential activity also runs 50 times. The developer moves it into Initialization.
- A second profiled run shows the batch now takes under three minutes. The developer imports the first session to compare the two runs activity by activity.
Profiling Versus Other Tools
| Tool | Answers |
|---|---|
| Profile Execution | Which activities take the most time, and how often they run |
| Execution Trail | Which path the workflow took |
| Logs and Log Activities | What happened, in order, with Trace detail |
| Orchestrator monitoring | How jobs and queues perform in production over time |
Use Profile Execution while developing and before release, then rely on monitoring and logs in production.
Exam Tips
- Profile Execution is started from the Debug ribbon and results appear in the Profiling panel.
- Container durations include their children; drill down to the leaf activity.
- Debug-mode profiles can be slower than normal runs.
- Profiling sessions are stored locally and can be imported later.
After a profiled run, a top-level Sequence shows most of the execution time. What should the developer do next?
Conclude that the Sequence activity itself is slow and replace it with a Flowchart.
Ignore it, because top-level containers are excluded from profiling.
Rerun the workflow in Picture in Picture.
Expand the tree to find the child activities that consume the time, because a container's duration includes its activities.
Where can a developer see how many times an activity ran and its average, minimum, and maximum duration?
In the Execution Details at the bottom of the Profiling panel.
In the Watch panel.
In the Orchestrator Jobs page.
In the project.json file.
Why might a profile collected while debugging differ from production timings?
Profiling is disabled for debug sessions.
Debug sessions always run at Slow Step 1x.
Profiling data generated during debugging can differ from data generated when running the file.
Imported sessions replace the durations with averages.
Sections you finish are checked off in the contents.