Toggle Breakpoint Shortcut (F9) - Saving the file?

Hi everyone,

Recently, the company I worked updated the UiPath Studio to 2023.10.4.

Now, using the F9 shortcut to toggle breakpoints became pretty slow, I noticed the F9 shortcut is also saving the file (this explains the slowness), and this is terrible if this is by design (hope this is a bug).

Is anyone else also facing this problem? Is there a way to change this behavior?

How could it change a breakpoint without saving that change to a file?

Are you working across a VPN and/or from a network share? Copy the project folder to a local folder and work from there. It’ll all be MUCH faster.

Hi @postwick , I working in the client’s remote computer.

I’m just saying, F9 shortcut is saving the file. This shortcut should not saving anything. Ctrl+S is to save, just it.

During the code changes I’m also adding breakpoints for as soon as I run the process I want to go through that breakpoints. But now, every time I hit F9 it is saving the file (this is not what previous versions was doing and it should NOT do it).

This is not the purpose of F9 shortcut.

I’m not sure why you care that F9 saves the file. It’ll save when you debug or run it, anyway.

I understand @postwick , I’m just pointing this out because toggling breakpoints now takes about 2 seconds to happen when using the shortcut. (please notice this happens even if the file is already saved)

Now it is faster right-click and toggle the breakpoint from the context menu than using the shortcut.

I don’t think this is the experience UiPath want for their product. Simple like that.

1 Like

In addition to that, I did more tests.
I was monitoring on the Task Manager why it is taking so long to add a simple breakpoint.
The CPU goes from 0% to 25% of usage just to add or remove a break point through the shortcut. (This is insane).
Something much more problematic is happening behind the scenes.

Studio is known to be very “chatty” with respect to disk read/writes. Are you working across a VPN or from a network share? It’s much better to have your project in a folder on your local machine.

Also, it’s normal for applications to take as much of the CPU as they can so tasks get completed quicker. If there is 80% CPU left, why not use it instead of doing the task more slowly?

Toggle breakpoint using the shortcut or pressing the button in the ribbon bar should be as fast as the option in the context menu (right-click > toogle breakpoint).

See, what bothers me is when I want to remove a breakpoint, previously I could simple hit F9 twice and it is done. Now it is faster “Rigth-Click > Toogle Breakpoint” twice than use the shortcut. This is completely non-sense.

Sadly I can’t record and share this because it is blocked by company network policies, I think this “feature” is also present in the community version, I’ll try to simulate it later in my personal machine and share.

Hi @postwick , below is the representation of what I mentioned in this topic. (To be able to simulate it in my machine, I had to add several activities to make the .xaml file big, they are collapsed in the If statement).

From the context menu, the toggle breakpoint happens instantaneously, from ribbon bar (or shortcut) the time it is taking is really bad.

Note there is no “changes to be saved” in the Main.xaml workflow, and so, there is no plausible reason for this slowness.

Toggle breakpoint from the context menu, from the Ribbon bar or from the shortcut should invoke the exactly same function/method internally. But it is clear the UiPath team is using a different way for the Ribbon/F9 and context menu. (Why?)

I hope they can rollback with this change or at least give to the users an option to “Do not save the file on toggling breakpoints” and ensure the performance would be as good as in the older versions of the product.