Having successfully upgraded to occ 6.9.0 and noticing great improvements in Boolean performance I have subsequently experienced a significant problem with cylinders cutting cylinders and also any half space cutting operations with semi-infinite prisms that have curved edges on the swept face.
It appears that they are incredibly slow in most circumstances. For cylinders it seems to be related to the resolution of the step size in IntCyCyTrim. Basically for my models the code which increments the variable 'anU1' only increments it by a very small amount each time (~0.003). This is because the variable 'aMinUexp' is always a small variation of the previous value due to the step variable.
In the code there is a while loop starting at line 2368 of file IntPatch_ImpImpIntersection_4.gxx
The issue is that 'anU1' takes thousands of iterations before it is less than 'anUl' for simple cylinders. This can take minutes up to hours to complete depending on the size of the shape, for example semi-infinite prisms can take up to an hour to complete. I have raised the query on the OCC main forum and been requested to re-raise it here. On the main forum http://www.opencascade.org/org/forum/thread_27145/?forum=3 there are a pair of cylinders produced by BRepTools::Write that reproduce the problem. If the Cut operation of c from b is executed on 6.5.4 in draw.exe everything runs as expected and quickly. On 6.9.0 the performance is very slow and instead of returning the result shape, the original body is returned, no cut is performed.
I have found that with semi-infinite prisms that have non planar surfaces the same problem occurs but can be reduced significantly by making the prism finite and with a much smaller extrusion. It leads me to believe that the step that is calculated for iterating around the curve of the solid is small compared to the size of the extrusion and causes many executions. This is a wild guess though.
Hope this is enough information and someone can help, I have tried to debug the code and find the reason but it is a little beyond my understanding, I know from performance analysis the time is consumed by the single function CylCylComputeParameters however i think this is simply because it is being called many, many times.
Anyone got any ideas, is it something I am doing wrong with the geometry?