Performance improvements for PartDesign patterns (PR)
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
-
- Posts: 529
- Joined: Fri Sep 18, 2020 5:40 pm
Performance improvements for PartDesign patterns (PR)
Hi all
This is the discussion thread for PR 4504. That includes some performance improvements for the PartDesign pattern operations (MultiTransform, PolarPattern, LinearPattern, ...).
Benchmark model:
https://github.com/FreeCAD/FreeCAD/file ... knurls.zip
Timing results:
Before
Time until UI becomes responsive after recompute: 3 min 45s
After
Time until UI becomes responsive after recompute: 56 s
Changed behavior
- A change in behavior compared to before, is that the Transform will not fail if one of the feature copies "misses" the base object. Now, a warning will be issued, but the command will carry on and simply keep the first solid (which hopefully is the base object). I think it is also kind of a feature. Edit: If you think that the old feature adds significant value, I think I can add it back. Let me know your thoughts.
- There is no guarantee that entities will have the same naming as before (maybe they do). So there is a risk of topological naming problem in sensitive models.
For sure it would be nice with some support on the testing of this, as there are many Pattern types and potential issues. For example, this PR, if merged may or may not cause topological naming problems in existing models (that are sensitive to that). That may be worth it. Or maybe we should support the old calculation as well, in order to not break old models. That would come with some additional complexity of course.
This is the discussion thread for PR 4504. That includes some performance improvements for the PartDesign pattern operations (MultiTransform, PolarPattern, LinearPattern, ...).
Benchmark model:
https://github.com/FreeCAD/FreeCAD/file ... knurls.zip
Timing results:
Before
Time until UI becomes responsive after recompute: 3 min 45s
After
Time until UI becomes responsive after recompute: 56 s
Changed behavior
- A change in behavior compared to before, is that the Transform will not fail if one of the feature copies "misses" the base object. Now, a warning will be issued, but the command will carry on and simply keep the first solid (which hopefully is the base object). I think it is also kind of a feature. Edit: If you think that the old feature adds significant value, I think I can add it back. Let me know your thoughts.
- There is no guarantee that entities will have the same naming as before (maybe they do). So there is a risk of topological naming problem in sensitive models.
For sure it would be nice with some support on the testing of this, as there are many Pattern types and potential issues. For example, this PR, if merged may or may not cause topological naming problems in existing models (that are sensitive to that). That may be worth it. Or maybe we should support the old calculation as well, in order to not break old models. That would come with some additional complexity of course.
- Attachments
-
- new_behavior.png (64.36 KiB) Viewed 2936 times
-
- old_behavior.png (61.38 KiB) Viewed 3370 times
Last edited by davidosterberg on Sun Feb 28, 2021 3:25 pm, edited 6 times in total.
Re: Performance improvements for PartDesign patterns (PR)
What would it take to implement the interruptable progress indicator here? I have not looked into what threading mechanisms we are using elsewhere in FreeCAD, but this seems like it might be a nice place to test out using OpenCASCADE's interruption mechanism and generate a proof-of-concept that can perhaps be applied elsewhere.
-
- Posts: 529
- Joined: Fri Sep 18, 2020 5:40 pm
Re: Performance improvements for PartDesign patterns (PR)
Good idea. I didn't know about this possibility. I will for sure look into that.chennes wrote: ↑Sun Feb 21, 2021 6:31 pm What would it take to implement the interruptable progress indicator here? I have not looked into what threading mechanisms we are using elsewhere in FreeCAD, but this seems like it might be a nice place to test out using OpenCASCADE's interruption mechanism and generate a proof-of-concept that can perhaps be applied elsewhere.
Re: Performance improvements for PartDesign patterns (PR)
This is significant improvement. What could be a good benchmark is to have the exact same part modeled in CSG way with Part/Draft.
If you attach the FreeCAD file I can add it inside.
If you attach the FreeCAD file I can add it inside.
-
- Posts: 529
- Joined: Fri Sep 18, 2020 5:40 pm
Re: Performance improvements for PartDesign patterns (PR)
It should be similar (i had a look in draft array for inspiration):
https://github.com/FreeCAD/FreeCAD/file ... knurls.zip
Re: Performance improvements for PartDesign patterns (PR)
Here are two examples in the topic: https://forum.freecadweb.org/viewtopic.php?f=3&t=55192.
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
Re: Performance improvements for PartDesign patterns (PR)
Do I need a self compiled build to test this, or will an update from the PPA tomorrow suffice?
-
- Posts: 529
- Joined: Fri Sep 18, 2020 5:40 pm
Re: Performance improvements for PartDesign patterns (PR)
OK, been meaning to do this for a while.
-
- Posts: 529
- Joined: Fri Sep 18, 2020 5:40 pm
Re: Performance improvements for PartDesign patterns (PR)
Thanks. An initial observation is that the new version is more memory hungry than the old version. This is not surprising, because it is running in parallel. But it may be a practical problem for extreme models like this. I actually ran out of memory on my laptop (8GB ram). Have since increased the swap file and expect the model to compute. But at that point it becomes IO constrained and slow.chrisb wrote: ↑Sun Feb 21, 2021 8:29 pm Here are two examples in the topic: https://forum.freecadweb.org/viewtopic.php?f=3&t=55192.
Edit: There are still things that can be improved. I am still running out of memory (and I have increased swap file size to 40GB ). Meanwhile I tried your Draft/Part solution in the linked thread. And it worked in seconds. That is positive news. Time for some further improvements.