Feedback about Studio performance

I just upgraded to Studio 2023.4.4. The more complicated you make it, the worse it gets. It seems like the idea that when something works just fine don’t change it for no reason is lost on your developers. Maybe you need to get feedback from the developer community BEFORE making changes, not after.

For starters, the memory usage (leak?) problem has gotten worse not better. Simply having a basic project open, not even multiple, and the UiPath memory usage is over 1GB.

It takes a lot longer for Studio to start Running/Debugging a process now, and this is going to eat up tons of extra time for me every year. I click that button dozens of times a day.

The “indicate” process is often much slower to start now. And for some unknown reason, it keeps coming up with computer vision enabled which I don’t need and have literally never needed. So I have to press F8 to turn it off then wait 5-10 seconds to be able to indicate an element. More wasted time over and over and over.

The time it takes to validate after I type or edit an expression is now much longer than it used to be. More wasted time, thousands of times a year. Sometimes it takes almost a minute for the red “error” icon to disappear from an activity. Sometimes it refuses to disappear, even though the expression is correct. So then I have to delete and re-add the activity and re-code it. More wasted time.

Moving everything out of the Properties panel and into the activities in the designer canvas is also a design deficiency. What’s the point of the Properties panel now? Having huge expanded activities in the canvas now takes up much more space, which means when I am looking for a particular step in my code it takes more scrolling (which is now slower) which…wastes more time.

These expression boxes, like in the new If activity:
image

I don’t need this. I’m a developer. I’m perfectly capable of just writing a condition statement, I don’t need this hand-holding that should be reserved for StudioX. Now I have to click the + icon, then select Advanced Editor…extra clicks, more wasted time.

The visual appearance - these vertical lines that thicken with what’s selected, now every box has the same top and bottom horizontal line, orange left border for some activities but a blue left border for others…what a mess. Grey box for unselected activity, blue box for selected activity - this was simple and easy and made it easy to see where the activity ENDS which is the most important thing. When I’m trying to add another activity at the bottom of something that’s nested in something else, now it’s difficult to tell where to put it. We work vertically, not horizontally.

And now it just crashed after I indicated an element. Probably because it’s using 1.5GB of memory. Killed it, reopened the project, immediately using 1.1GB memory.

9 Likes

I second the opinion. As a developer, I find the new design somewhat frustrating and not aligned with my expectations. I believe that UiPath could have maintained the distinction between Studio X and Studio, each catering to different user profiles, while concentrating on refining and enhancing the features tailored to those specific needs

3 Likes

I have to agree with these comments I made a suggestion a year and a half ago that would make it easier to find the top and bottom of the Sequence, Do, For and If activities. this has made it even harder to find them. Having comments allowed at both top and bottom with being able to go to or edit the top or bottom comment. Currently in all my Programs I use the Comment activity at the end of these activities and name the activity so I can search the activities to find the comment I placed at the end of each.

2 Likes

I just did a Convert on one of my Windows Legacy to the new Windows, And I see that the ability to add annotations on the Then and Else sequences has been removed. I used this capability consistently to denote what the program expectations for the Then and Else were to clarify usage for other programers that may need to update my programs. Alo I updated the Then and Else names to include a short description that I used in the Universal Search to easily get to specific If Then or Else activities in my program. All are now marked with the generic Then and Else, the customizable name feature has been removed. This pretty much severely limits the search capability. Now I will need to add comment activities at the beginning as well as the end of Then Else to easily find locations within the program for updates.

1 Like

Also, along the lines of the Properties panel now being pointless - it used to be easy to update the names of activities. This is part of our coding standard, and of course good practice in any case. Name activities to give information about what they’re doing and also to aid in debugging.

As mentioned above we can no longer change the name of the Then/Else blocks.

Also, having to double click the title of an activity - in just the right spot, no less - is painful. We used to just be able to single click or do it in the properties. Now those capaibilities are gone. When trying to double click I often end up zoomed into the activity instead of being able to change the name - losing my place in the code. And when an activity stretches off the bottom of the screen, the first click of the double click bounces it up so the top of the activity is aligned with the top of the designer canvas. This is terrible. Stop moving things around out of our control.

1 Like

Hi @postwick ,

Thank you for taking the time to share this detailed feedback. We’ve tested what you described in this post and can confirm that the issues raised are valid. Thus, I would like to understand a bit more about the impact of these problems you are facing in 23.4.4 so that we can tackle them in the best way possible and for that I have a few follow-up questions/comments:

  • What version of Studio were you using before this? This would help us set up a baseline to estimate the impact when looking into these issues.
  • Do you experience the slowness in Running / debugging a process on compilation or in validation or does this happen at a different stage?
  • Regarding the slowness of the indicate experience, indeed it is mainly caused by CV being enabled by default as targeting method in Unified Target. To workaround this while we’re working on fixing this, you can disable CV in Project Settings > UI Automation Modern > Targeting methods (Desktop, Java or Web - for SAP it’s already disabled).
  • For the expression validation, do you notice the validation time increase or the issues regarding the validation on certain activities or does it happen consistently on most activities?
  • The Properties Panel should still be available in Studio and you can avoid having expanded activities by going into Backstage> Setttings>Design and set Show activity properties inline to No as below. I believe this should be default in Studio but do let me know if that’s not the case.
  • For expression boxes, I understand it can be cumbersome to have to do multiple click in order to get to the Advanced editor. To avoid that, you can use the Expression Editor to write expressions in line if you’d like to avoid the builders but we should also make it easier to reach the Expression Editor with less clicks.

Many thanks,
Raluca

1 Like

Prior to this we were on 2021.10

From the time I click Debug to when the validation window appears, that’s what takes a lot of time now. Also, with respect to Debug, I noticed while a process is running in Debug mode you can still edit the activities - but those changes are not saved, they revert. Everything used to be read-only when Debug was running, and it should be read-only.

Excellent, I will keep this in mind.

I haven’t really paid attention to that level of detail. I will try to get a sense of this for you.

It is not the default, at least not for me. Possibly this is because I was upgraded to 2023.4 rather than installing it from scratch. However, knowing about this setting is very helpful, I will try it. Thank you.

I just tried turning this on and Studio crashed when trying to refresh the project. I got the “critical internal error” message. I tried closing all projects I had open in Studio, opening just one project, and turning this setting on, and I didn’t get any errors - so I suspect the crash was because it tried to update a Studio setting with other Studio windows open.

Properties are now showing in the Properites panel, but not for all activities. For example, the “If” activity says “All properties are visible within the activity card.” I should see the properties in both places.

Another example is Orchestrator HTTP Request. It says "properties for this activity are located inside the activity card under “advanced options.”

So while this setting is an improvement, it’s still hit or miss. And the properties are still being shown in the activities in the designer canvas, which doesn’t solve the issue of screen real estate usage. I’ll have to get more familiar with how this setting affects screen real estate usage, though, as I use more activities with the setting changed.

One other thing I’ve noticed as I use 2023.4.4…I often cut/copy and paste activities to reorganize things. It is very, very common now that it won’t let me paste where I want to. I right-click on the (+) icon and Paste (along with a lot of other things) is greyed out.

1 Like

I also get “not enough quota left to process this command” quite often, specifically when saving a form and closing the form designer (UiPath.Form.Activities 2.0.3)

I think there is quite some valid feedback in this, especially things like the properties panel.

I think its great that UiPath keep updating their software with new features and some are really great, the activity layout for library activities is awesome, coded workflows are a game changer in my opinion, but often I think the target audience is abit… unclear.

Sometimes you do stuff really cool that is clearly focused on developers, sometimes you really tie a developers hands behind their backs because you remove some detailed functionality we previously had, sometimes you just seem to forget things (an example is the newest Data Service Activities where adding a file to a data entity used to just require a file path whereas now it requires an argument of iFileResource, which isn’t documented requiring me to hunt in your library source code for a class that implements that interface).

I’d love it if you did these new things in a more staggered approach, where the old functionality still exists but we can choose to perhaps use the new stuff. Like how the data manager was implmented, I can still use the old arguments and variables pane but I could now use the new option.
Do the same with the properties panel, let us toggle between new view and old.

You get the idea, I realize you want to make it as simple as possible for low coders but also recognize many UiPath people are more skilled developers and want the more advanced features available.

They did reply above with this:

Although it still doesn’t return it to exactly the same functionality as before, it’s better than nothing.

Yeah, I was aware of this, but I want the old style properties panel to be an option besides the new style WPF layout stuff.

1 Like

Hello! I can give you some insight into the reason why the old view was not kept as an option.

In order to support cross platform projects, the way activities are defined was completely remade. The old properties panel was actually a rehosted component that could only interpret the old activity definition style, so it would not work at all with the new activity definitions.

The only activities for which the old property grid can be (and is) still displayed are some of the activities from the “Default Activities” category, which have the benefit of being deployed with Studio.

In order to keep the old view, it was not just a matter of toggling a flag, but we would have had to rebuild it basically from scratch (including adapting display styles for each individual control ex. expression boxes, combo boxes etc.), besides building the new property display view.

This is part of what I’m saying shouldn’t have been done. We’re developers, we don’t need all this handholding of these fancy controls, expression boxes, etc. And nothing should be a combo box - because then we cannot use expressions. For example, the Status property of Set Transaction Status being a pulldown means we need to branch with an If/Then and two nearly identical Set Transaction Status activities - instead of putting a variable or expression into Status. These are the kind of improvements we needed - being able to use expressions for all properties.

Trying to meld Studio and StudioX is a mistake.

@postwick Well that is mostly up to the activities themselves and the way their properties are defined. Hover over various activity property names (in order to see their type) and you will notice that wherever the property type is InArgument<T>, you will be able to use variables, but where the property type is just a regular type (ProcessingStatus for your example) you will not be able to.

As a different example, check out the property User data folder mode from the Use Browser activity, and you will notice that you can both pick a value from the combo box and use a variable.

That’s the basic rule. If the activity expects an actual value, you can’t really pass it an expression and expect it to figure it out, as it won’t be compiled, whereas (In,Out,In/Out)Arguments can handle it.

As for what I was saying earlier, combo boxes were always present in the properties panel, even in Legacy projects, so at least for backwards compatibility if not anything else, they would have had to be displayed as such.

So please make everything InArgument. It’ll be a huge improvement.

Thanks for the explanation David, that indeed does provide extra insight.

I can live with the new format based on that reasoning if we can find a way to not lose the functionality we had.

I was aware of how the differences between InArguments and properties worked and it always boggled my mind how/why some core activities, especially related to Queues have properties instead on InArguments forcing you to hard code values, the most egregious being the set transaction status which has the Output as a property meaning you must key in each dictionary key hardcoded.

This is obviously a separate issue, but things like this are soooo simple to fix.

More problems with the validation giving incorrect results.

I have a variable fileInfoCollection which is System.Collections.Generic.IEnumerable(of FileInfo)

I am trying to assign to it:

New System.IO.DirectoryInfo(currentPath).GetFiles.OrderByDescending(Function (d) d.LastModifiedDate).Where(Function (f) f.LastWriteTime.Date = FilterDate.Date)

No matter what I do, it keeps telling me:

It keeps seeing the DirectoryInfo.GetFiles result as an Object when it’s not. It’s IEnumberable(of FileInfo).

I have tried everything to get this to go away. More than one Assign is doing this.

However, in another section I can assign this to fileInfoCollection and it doesn’t cause any errors:

New System.IO.DirectoryInfo(currentPath).GetFiles.OrderByDescending(Function (d) d.LastModifiedDate).Where(Function(s) Split(transactionItem.SpecificContent("Extensions").ToString,",").Contains(s.Extension) And s.LastWriteTime.Date = FilterDate.Date)

I even copied that expression to the Assign that won’t validate correctly, and it gives me the error.

Two different Assigns with the exact same statement. One validates fine, the other sees the DirectoryInfo.GetFiles output as an object.

I even cut the expression down to the bare minimum:

New System.IO.DirectoryInfo(currentPath).GetFiles

And it still thinks this returns Object.

If I cut the activity and paste it back in, the error goes away:

image

However the parent activity, a Switch, still has the yellow ! icon on it. And when I try to debug, the validation step spits out errors and we are back to the Assign not validating and the error showing on the Assign activity.

I have observed that sometimes the assign gets messed up, I encounter it mostly when I am using coded workflows where it seems to struggle to determine the object type and defaults to ‘Object’.

I find that sometimes deleting the assign and then adding it again fixes the issue, in an extreme scenario you can edit the xaml so the data typing matches the ‘good’ assign you have.

If this is a common issue then that it annoying, at least in my experience though the assign is pretty good at determining the data typing except on coded workflows so I hope/think this might be a small bug you got stuck in here unless you say it happens on lots of different assigns?