issue Performance and other issues when editing Business Processes

[samwoo]

Hello,

For a while now at least a couple of months, I have been having performance and other issues with the Business Process editor. It doesn't matter what device I use or where I do the work (at the office, or at home with a 1Gbps connection) I always have these issues.

----------------------------------------------------------------------------------------------------------------------------------------------------------

Performance Issues
This does depend on the complexity of the Business Process, and unfortunately in some cases the complexity is required. For example this is the performance of just trying to join 2 x "Via" nodes together on one of the stages in the new version of our Movers Process.

If I need to join other nodes, I have to wait for this amount of time, almost each time.

I am using the latest version of Edge on all devices.

Our BPM autosave interval is every 3 mins. I found having it do it ever 1 minute was too excessive as even when saving, it's like the page is reloading... can take a bit of time, though not as much as above. 

Also wanted to point out that the slowness and performance issues can also occur when creating new nodes or navigating to a stage with lots of nodes etc. And, sometimes I don't get the performance issue for 5 to 10 mins, then they suddenly come back.

Eventually, if I've been working on the BPM for long enough, I get the browser has run out of memory error. Very frustrating, especially if I was in the middle of doing something and haven't been able to save my edits.

----------------------------------------------------------------------------------------------------------------------------------------------------------

Editing Issues - "Via" nodes moving despite not being selected

If I select a node, then attempt to move 1 node (or more if I drag to select), any directly connected "Via" nodes, whether upstream or downstream, and even other "Via" nodes connected to those "Via" nodes will move in one go. Means if I need to move anything down, I have to constantly reformat the Business Process.

Here is an example. Say I want to move either of the Human Tasks down, or the Get Request Details (Again) node down (using my Keyboard)

This is made worst if needing to move groups of nodes down that have multiple "Via" nodes connected to them in the name of formatting... as not having this "Via" nodes in there would make the BPM extremely hard to read... so it's a necessity for me, but when they all move it becomes a massive headache to sort out. I have to break any via nodes between the groups and move them broken before reconnecting them again... then *sigh* the performance issue above occurs.

----------------------------------------------------------------------------------------------------------------------------------------------------------

Editing Issues - Moving nodes outside of the existing Canvas, ruins any groups.

If I have a large and complex BPM and I need to add in a node to the top but it would take a long time to move everything down manually, in the past I would just move the "Start" node outside of the boundary either using my mouse or keyboard.

Unfortunately in the last couple of months this has not been possible, as it would cause any nodes within groups to move whilst the groups remain intact (it might be the other way around, but I can't tell).

Here is an example of my new version of the Mover Process. Note if you see off the right side, it looks messy... I was unfortunately to have this issue occur just before the process automatically saved last week, so I need to tidy it up (facepalm).

This is the result of moving an extra node at the top. Please note this happens regardless of the complexity of the Business Process. I was able to quickly refresh my screen to prevent the process from autosaving this issue (phew!)

----------------------------------------------------------------------------------------------------------------------------------------------------------

It's late so I will log a support call tomorrow morning and link back to this topic.

Thanks,

Samuel

 

[NeilWJ]

Hi sam,

When you raise support request can to attach those processes to the call. The memory issue might be some digest loop so if we have your process that causes it should be able to identify quickly, save us having to try replicate.

Cheers

[samwoo]

Thanks @NeilWJ - will do.

Have a good night! (or good day?)

[Victor]

@samwoo it would have been a "good night" for him most likely... update:

Fixed (pending an update):

• moving node off canvas does not reposition groups or notes
• via connection nodes auto moving when moving nodes connected to them

In Progress:

• performance (possibly memory leak) when editing complex workflows

[NeilWJ]

Hi @samwoo,

Ok so have worked on performance when moving stages. Basically every time something is moved the connector between it and any other nodes has to be re-rendered. That isn't a simple calculation. It has to work out at which point on src node boundary to start connection and which point on the target node to end connection. It then also has to work out if and where out where it needs to bend the connection. Once that is done it then needs to actually render the svg.

You then take into account that you are either holding down one of the arrow keys or dragging with mouse.....this fires move event, lets say every 1ms, so every 1ms the browser has to redo all the positioning calculations and re-render for the nodes being moved and the affected connections....it is not trivial processing going on here.

The only way to really improve performance when dragging groups around is to hide the connections (svg) in the group so that don't need to do the calculations. Then once stopped moving re-render them. So that is what I have done, obviously the effect of this is when moving groups the connections dis-appear.

There isn't really anything else that can be done to improve performance.


Regarding memory usage i found a couple of places where memory pointers would not be cleaned up properly so have also added in handlers for that. Hopefully that will sort out memory issue. When testing I saw a good drop in memory usage after putting in the handlers and when switching through stages.


Lastly before the changes when i loaded that second stage it would take about 3 seconds to render. That is now down to around 1.5 seconds. That though is running on my dev box though which is a pretty fast pc but none the less there is an improvement there, it might be greater for you or not so much. Also found that when switching away from that stage it took even longer to destroy it, was taking about 4 to 5 seconds. I have sorted that out and now switching out of a stage should be noticeably faster when you switch out from one with lots of nodes and connections....the destroy process only takes about 200ms at most now.

I have also kept some console logging in to display the stage rendering times....i will eventually remove this stuff but kept it in so you can check what sort of timings you are getting.

You should see these changes in Core UI build 1718 and onwards

Cheers

[samwoo]

Thanks for the update @Victor and @NeilWJ!

I'll be sure to feed back once it's in - but thank you for looking into this.