Performance of multiplying Occurrences and adding Joints

Performance of multiplying Occurrences and adding Joints

Anonymous
Not applicable
771 Views
3 Replies
Message 1 of 4

Performance of multiplying Occurrences and adding Joints

Anonymous
Not applicable

Hey there in my Add-In I offer the possibility to bulk join a component the following way: 

performance.gif

 

Now I wanted to tweak the performance a little bit. I found out that the following functioncalls are consuming most of the time.

 

...
newOccurrence = rootOccurrences.addExistingComponent(componentTwo, matrix)
...
joints.add(jointInput)
...

each consuming ~0.3s on my (decent) hardware. Summed up they are consuming 95% of the time my script runs.

 

I tried tweaking with threading and multiprocessing in python.

Threading is a little bit faster but the improvements are neglegtible. Multiprocessing is not any better.

 

Is there anything else to get faster results (except using C++)? Does someone tried making a comparison of Python and C++ on one of those specific function calls.

 

 

0 Likes
Accepted solutions (2)
772 Views
3 Replies
Replies (3)
Message 2 of 4

JesusFreke
Advocate
Advocate
Accepted solution

I ran into the same performance issues when designing my fscad library. At first I was creating a new component for every operation, and it became slow to generate a design very quickly.

 

The biggest thing I did to improve performance was to use the TemporaryBRepManager and work with temporary brep objects as much as possible, and only creating a component at the end, and importing the bodies into the component. I'm not sure how applicable that would be for your situation though.

Message 3 of 4

BrianEkins
Mentor
Mentor
Accepted solution

The API in Fusion runs in the main thread so any attempts to run code in a separate thread won't end up helping.  The C++ API is what's implemented internally.  Using C++ calls the API directly and using any other language goes through a wrapper but also ends up calling the same internal C++ functions.  There is some overhead because of going through the wrapper but in most cases, it's probably not enough to matter.  Let's say there's an overhead of .005 seconds per API call.  (I haven't timed this but my guess is that this probably isn't too far off.)  If you have a program that's making thousands of calls through the API, then it could start to make a difference but otherwise, it's probably not enough to worry about.  

 

The other area that will contribute to the performance difference between Python and C++ is what you're doing exclusively within your program.  If you have a lot of data that you're crunching a C++ program is probably going to be faster.  In your example, I would guess you won't see much difference if you re-wrote your program in C++.  It would be an interesting test though.

 

I think mostly what you're seeing is the performance of Fusion itself.  Whether you make a call from C++ or Python, the actual handling of that function call by Fusion is going to take the same amount of time.  If it takes 0.3 seconds to copy and paste a component in the UI you don't really notice it but if you're doing that multiple times in the API, now it definitely becomes noticeable.  There's nothing you can do to speed up this other than possibly report significant issues and hope the development team can improve the performance.

 

I'm not sure where most of the time is being taken in your program between placing the new occurrence and adding joints.  The joint system is continually resolving when you add new joints.  One thing you could try, if that is what's taking a lot of time, is to play with moving the timeline marker so that most of the joints are beyond the timeline marker and won't be solved.  For example, you can create the occurrence and the needed joints, then move the timeline marker to before the joints and then place the next occurrence and joints and then move the marker to before these joints and continue this process.  At the end then move the timeline marker to the end.  I'm not sure if it will make much of a difference or not, but it wouldn't be too hard to try.

---------------------------------------------------------------
Brian Ekins
Inventor and Fusion 360 API Expert
Website/Blog: https://EkinsSolutions.com
Message 4 of 4

Anonymous
Not applicable

@BrianEkins @JesusFreke 

Thank you both for your answers.

 

I guess Temporary Breps are nice but i cant use them here because i want a component with a joint add the end. So not just add some special features. Further reading on Temporary BReps can be found here https://ekinssolutions.com/using-temporary-b-rep-in-fusion-360/

 

If I have more freetime I will make a test and post my results here. What I already found out is that it runs a lot smoother on Mac (it seems it does all computation at once).

 

I also tried to use the Timeline features but no great improvements there yet.

0 Likes