Community
Fusion API and Scripts
Got a new add-in to share? Need something specialized to be scripted? Ask questions or share what you’ve discovered with the community.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

c++ javascript or python?

5 REPLIES 5
SOLVED
Reply
Message 1 of 6
niklaskp
2669 Views, 5 Replies

c++ javascript or python?

Hi,

 

 

What API is most actively in development and what are the speed differences? Which one has most functionality implemented? Im guessing C++ should be the fastest but are the users using c++ or will the API die in the future? Would python be the second choice?  

 

I am about to write some scripts for fusion and would be great to get an opinion from the developers so I do not need to do the same job again in the future. 

5 REPLIES 5
Message 2 of 6
ekinsb
in reply to: niklaskp

There are several things to consider when choosing a language.

 

As far as the API for each of the languages being developed; functionality is delivered for all three languages at the same time.  Internally, we implement the C++ interface first but then wrappers are constructed automatically for Python and JavaScript.  So all three have the same capabilities.  However, there's one exception to this in that JavaScript doesn't support all of the events.  We ran into a technical problem with events and JavaScript so we've blocked exporting most events in JavaScript.

 

For speed of execution, C++ will be the fastest since it is compiled code that runs within the Fusion process.  On Windows and Mac, Python also runs in-process but it's interpreted and Python isn't known as a particularly fast language.  On Windows, JavaScript runs out of process and as a result is much slower.  On Mac, it runs in-process and is similar to Python.

 

For speed of development, much depends on which language you have the most experience with already.  A new language always has a learning curve at the beginning.  But assuming that you are comfortable with all three, I would say that Python is probably the language someone could develop code the fastest in.  One reason for this is that you do the development and debugging within the same IDE.  You can also do some prototyping using the text window in Fusion.  C++ has an advantage that it is typed so you're able to catch many problems while writing and compiling, while you end up debugging a lot of problems at run time with the other two languages.

 

Another thing to consider is if you plan to deliver your program commercially.  With JavaScript and Python you're essentially delivering your source code.  With C++ you're delivering a binary which is much harder for someone to crack.

 

If you don't care about the security of your code, I would recommend Python and if you do need to protect your code then C++.


Brian Ekins
Inventor and Fusion 360 API Expert
Mod the Machine blog
Message 3 of 6
jesse
in reply to: ekinsb

I had a couple follow up questions about this, as I'm considering using Javascript (actually, ClojureScript) for future add-in development:

  1. Is there a central list of events that aren't supported in Javascript?  I was looking through the events documentation for a command definition, and couldn't see any that weren't supported in Javascript, but I don't want to make the leap and then find out that I'm missing some required functionality.
  2. When you talk about speed of execution, are you looking at time to access the Fusion model / launch Fusion commands?  Or are you talking about raw horsepower available to run an algorithm?  My add-in is light on number crunching, but does a lot of interacting with Component and Occurrence objects (and a lot of interacting with command inputs).  If I switch from Python to Javascript, would I expect a noticeable decrease in performance?

Thanks!

Message 4 of 6
ekinsb
in reply to: jesse

There isn't a single list of events not supported in JavaScript but each event that is not supported has a statement in the topic for that event.  Actually it is in both the property that returns the event and the topic for the event.  Look for the statement highlighted below in those topics.

 

JavaScriptEvent.png

There's also the potential of having problems with some of the events that are not blocked for JavaScript.  We didn't want to take away any functionality when we discovered this issue so left all existing events still exposed but only started doing this for all new events.  It was thought that the command related events were OK but I recently ran into a problem when enhancing the spur gear sample so I ended up just releasing the update as Python and C++.  The symptom is that there ends up being a deadlock and Fusion will hang.  This is also only an issue on Windows because of how the JavaScript integration is being done on Windows. But because the API doesn't know where it's going to be used these events are blocked in all cases.

 

Regarding that Python is faster than JavaScript.  This is also a Windows only issue.  I didn't do any testing on Mac to see how the languages perform there but on Windows, JavaScript programs run out-of-process and incur a performance hit for marshaling the data between the two processes.  So, on Windows the cost of making an API call is much higher than with Python which run in-process to Fusion.

 

There is the cost of making the call, the cost of handling the call, and the cost of returning the results.  Depending on the operation being performed, the cost of Fusion handling the call is often the most time consuming and that will be the same regardless of which language is used.  It's just the cost of making the call and returning the results where JavaScript will be slower.  The actual cost for a typical program will vary significantly depending on what that program does.


Brian Ekins
Inventor and Fusion 360 API Expert
Mod the Machine blog
Message 5 of 6
carloquinonez
in reply to: ekinsb

I wish Javascript was more evenly supported across the platforms. It's the only language that works everywhere, including the browser. We use JS in all of our other projects, including cloud apps (Node), desktop (NW née Node WebKit), and mobile (Cordova). Code reusability and maintainability is lot easier when all projects are in the same language. As far as performance, my guess is that a well-written script/plugin is going to be spending >95% of it's time inside API calls, NOT in whatever business logic you've written in Python/JS/C++, so the overall performance isn't going to be significantly different between the languages.

 

I think the biggest question regarding which language is (or should be) "What languages will Project Leopard (Fusion360 in the browser) support for plugins and scripts?"


-CQ
Message 6 of 6
hithere8
in reply to: carloquinonez

I agree with carloquinonez, and wish JS to be fully supported.

 

In regarding to protect source code, JS code can be uglified such that it can be both protected to an extent, also code being minimized for faster running speed.

Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums  

Autodesk DevCon in Munich May 28-29th


Autodesk Design & Make Report