Blue Prism 7.4 Performance Issue – Slow Opening/Saving Due to Large Process and Object Size

[vrushalird]

Hi Community,

I’m currently facing a performance issue in Blue Prism v7.4 related to one of my automation processes.

Issue:

While opening, saving, or closing the process, Blue Prism takes a significantly long time to respond. Upon investigation, I noticed the following:

• The .bprelease file for this particular process is around 15 MB.

• One of the objects used in the process is 5.5 MB.

I suspect the large size of the process and the object is contributing to the slow performance.

What I’ve Tried:

• Checked for unused actions/pages and removed them

• Confirmed that this issue is specific to this particular process; other smaller bots don’t exhibit the same delay.

Questions:

• Are there any best practices to optimize process/object size in Blue Prism?

• Would breaking the object by sharing its Application Modeller with another object help?

• Would creating child-parent process help improving performance?

Any advice, tips, or similar experiences would be appreciated. Thanks in advance for your help!

Blue Prism Enterprise 

[SayeedBinAbdullah]

Hi @vrushalird 

You're right—huge process and object files can definitely slow things down. When files like your .bprelease or objects get too big, the system finds it harder to handle basic actions like opening or saving, especially while you're still designing the automation.

Yes, splitting the object and sharing the Application Modeller across multiple objects can help:

• It reduces the size of each individual object.
• Promotes reusability and separation of concerns.
• You can create a dedicated object just for the Application Modeller and expose it via shared actions.

Just ensure that shared models are well-documented and version-controlled to avoid confusion.

• Avoid embedding business logic in objects—keep them focused on application interaction.
• Remove unused actions, stages, and data items (which you already did).
• Minimize the number of attributes used for element identification.
• Avoid duplicating models across objects—reuse wherever possible.
• Disable or limit stage logging during development to reduce overhead.
• Avoid logging large collections or sensitive data unless necessary.

Also, creating a child-parent process architecture can improve performance and scalability:

• Parent process handles orchestration and queue management.
• Child processes handle specific tasks or transactions.
• This structure reduces the complexity of each process and allows parallel execution.

It’s especially useful when working with large queues or when different parts of the process can be decoupled.

Best Regards,
Sayeed Bin Abdullah

[asilarow]

@vrushalird - 15MB is on the bigger size for a release, but not to the point that it should affect your entire environment.

I have release files that are over 50MB in size, and everything works smoothly.

An object of 5.5MB in size is also not that unusual, especially when using surface automation and having images saved.

You say this happens in v7.4 - have you tried in other versions?

Also, are any other processes affected?

[vrushalird]

Hi @asilarow,

Thank you for your inputs.

Currently, I am facing slowness issue only for the 15MB process and the 5.5MB object in 7.4 version. I was facing this issue in the 6.10.2 version as well for the same process and object. Rest other components do not seem to have any issues while opening or saving them.

I think it was not clear in my previous post that only one process and one object is very slow to open or save. It is not affecting the entire environment. Hence, I feel that splitting the process and/or object might help.

Please let me know if there are any suggestions/advice to resolve this.

Thank you,

Vrushali Daware

[asilarow]

Hi @vrushalird ,

A couple of things come to mind:

• Check for large collections with a lot of data rows and/or columns in Initial Values 
• Check for images stored within data items
• Check for Binary Type Data Items - these can often cause memory issues
• Check the naming conventions of your data items - are there any special characters in any of them?
• Check for recursive naming on data items - are any data items named the same as a Process or Object?
• Check for errors - are there many unresolved errors?

Other than that... Yes, splitting it up into smaller processes is always a good idea.

Typically I recommend doing something as per below:

And then each page within the block calls a sub-process, providing inputs and validating the outputs as required.

The Object on the other hand, should definitely be split into smaller ones... but I wouldn't recommend using a shared application model unless you've done this before - it can get a bit tricky sometimes.

Also, change management is easier is you keep the application models separate.
Try to split them according to the below example (several objects maintaining an object per screen/area approach):