Personal tools
You are here: Home Forum Use SHAPER performance issues

SHAPER performance issues

Up to Use

SHAPER performance issues

Posted by BROY Maxime at November 02. 2021


We used SALOME SHAPER as our workshop to develop specific application, but we are now facing performance issues.

We noticed that performances are decreasing faster as the part becomes more complex. At some point, every operation becomes really slow.

I'm sharing a script we created to illustrate this. In the script you can modify the variable "nbRooms" to modify the number of partitions. When we did, here is what we observed :

The rate of the increased process time seems to be polynomial, which quickly becomes problematic.


Our application does not work exactly the same way, but we observe the same issue.

Can we hope for performance improvements in the next release, or can you provide some tips to avoid this issue ?


Thank you.

nb : we are using SALOME 9.6


Re: SHAPER performance issues

Posted by Mikhail PONIKAROV at November 02. 2021

  Hello Maxime,

The problem is not in SHAPER, but in the calling of modelization core (which is Open Cascade Technology here) in quite not-optimal way.

If the script is changed to call the partition feature only once with all planes as arguments, it works tens times faster. It could be like:

  partitionArgs = [model.selection("SOLID", "Extrusion_1_1")]

  for x in range(1,nbRooms):

    planeName = "Plane_" + str(x)

    partitionArgs.append(model.selection("FACE", planeName))

  Partition_1 = model.addPartition(Part_1_doc, partitionArgs)

The problem that in the sequential approach the partition algorithm should analyse intersection of new plane with all faces of results of previous partition. So, while the partition results become more and more complicated, each next partition becomes more and more slower. And this is true for any modelization core.
If all arguments are passed at once, this allows the partition algorithm to optimize it. I believe, the function time(number of rooms) will be still exponential, but with a much smaller scale factor.




Powered by Ploneboard
Document Actions