Freecad fails to be serious CAD because of poor language choice

Here's the place for discussion related to coding in FreeCAD, C++ or Python. Design, interfaces and structures.
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
user1234
Veteran
Posts: 3319
Joined: Mon Jul 11, 2016 5:08 pm

Re: Freecad fails to be serious CAD because of poor language choice

Post by user1234 »

So is one month over again? Does someone new to complain about FreeCADs speed, whos do not know to use it properly? When i read stl, points (or facets) and serious in one line, without a not in it, it raises hackles.

Greetings
user1234
vm4dim
Posts: 129
Joined: Tue Nov 23, 2021 1:05 am

Re: Freecad fails to be serious CAD because of poor language choice

Post by vm4dim »

andremiv wrote: Sat Jan 08, 2022 11:43 pm so why not let the user provide tooth profile : https://www.desmos.com/calculator/yrihyyn5ek, then compute the worm screw from profile, then compute the gear from the screw.
Export desmos as SVG.
Import SVG in FreeCAD.
Extrude it.
Attachments
desmos.png
desmos.png (21.77 KiB) Viewed 2093 times
User avatar
Chrismettal
Posts: 43
Joined: Fri Sep 18, 2020 11:44 am
Location: Germany
Contact:

Re: Freecad fails to be serious CAD because of poor language choice

Post by Chrismettal »

Without any language comparisons I would also say that FreeCAD tends to feel slower than other CAD packages and pointing that out isn't really a bad thing. "You are using it wrong" also can't always be the answer to that. Even a project done fully up to the community best practives, simple sketch based operations using datum planes everywhere, no references to anything that could trigger toponaming, becomes very slow when recomputing, which other packages just don't. Even importing an .stl to work on it is manageable in other packages. If the community insists on "It's slow and bad practice, don't do that" why do we have the option?

So, unbiased investigating and benchmarking is a very good thing in my book. But not because "C better lol".

I am happy to hear if you find any speedups in porting code from python to C/C++.

Half related - I am also not a big fan of mixing languages and did not yet get why we do it, but I wouldn't go as far as to call FreeCAD not serious or unviable for professional use because of it.
kisolre
Veteran
Posts: 4162
Joined: Wed Nov 21, 2018 1:13 pm

Re: Freecad fails to be serious CAD because of poor language choice

Post by kisolre »

Chrismettal wrote: Sun Jan 09, 2022 8:20 am I am also not a big fan of mixing languages and did not yet get why we do it,
Macros? Easy workbenches?....
chrisb
Veteran
Posts: 53919
Joined: Tue Mar 17, 2015 9:14 am

Re: Freecad fails to be serious CAD because of poor language choice

Post by chrisb »

If we wanted to have makros and only a single language involved, we would have to use solely Python or something similar. Not really a speed booster.
I am not really a friend of C++ - not as close to the machine as C, not as high level as modern object oriented languages - but it seems to be a very good compromise between performance and abstraction.

The combo Python/C++ is indeed a good one, if Python is used as a wrapper for C++ implemented time consuming functions. If things get too slow in Python, there is always the possibility to re-implement them in C++, which doesn't require a complete redesign.
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
abdullah
Veteran
Posts: 4935
Joined: Sun May 04, 2014 3:16 pm
Contact:

Re: Freecad fails to be serious CAD because of poor language choice

Post by abdullah »

Chrismettal wrote: Sun Jan 09, 2022 8:20 am I am also not a big fan of mixing languages and did not yet get why we do it
Python is not slow at all for the type of language it is. Without making any choices you get about the fastest in average choice you can get (for example hash-table based dictionaries are the default thing you get as a dictionary. Key to value in constant time. Memory management is rather good for generally not having to take care of memory management). Python has an extremely low entry point. This does not mean that anyone is a great Python programmer, but that anyone can program Python (If you saw "Ratatouille", the film, it is about the same, everyone can cook. I can cook. I am not a good cook. I can program Python. I am a very bad Python programmer). This is a fact, it is the most used programing language. Within FreeCAD, Python enables very powerful interaction with CAD. It enables a lot of custom operations directly from the Python console. It is a key ingredient for the success FreeCAD is. Since I realised this power, I have a greater incentive to work harder on the Python bindings.

Python is slower than C++. C might be slightly faster for some specific operations. Assembly might be faster than C and C++ for some specific operations. The whole FreeCAD could be written in Python. Then it would be slower than it currently is. It would still offer a lower entry point, maybe even lower. The use of C++ does however speed up FreeCAD while maintaining the convenience of being fully Python operable. This enables to do trade-offs and improve bottlenecks.

I like C language quite a lot. However, C language is not close as expressive as C++. It is not true that one cannot create complex projects in C, but generally C++ excels over C in managing complexity. C++ is evolving (it is in a quite lively development), it is getting better and better. Because FreeCAD is a rather complex project, we need a tool able to manage complexity and at the same time is fast. C++ enables more people to approach the code than C would. I know no other language that better matches these two requirements (complexity management and fast execution) than c++.

In fact, a discussion Assembly vs C would also raise those very same points (also others). Assembly is the fastest you could get. Portability aside, in the size of codebase of FreeCAD would be simply impossible to handle. Unapproachable in practical terms.

The Python / C++ marriage is actually a very stable couple. They complement each other rather well. They is also a rather popular couple.

The inconvenient truth is that no other language or combination of languages beats this couple in speed, complexity management and flexibility.
User avatar
Chrismettal
Posts: 43
Joined: Fri Sep 18, 2020 11:44 am
Location: Germany
Contact:

Re: Freecad fails to be serious CAD because of poor language choice

Post by Chrismettal »

Thank you for the explanations. Especially for Macros or anything that an end user could touch I now understand that Python is definitely more manageable and I get why there are two languages involved.

Personally I still think that stuff that the user never sees and that has the potential of impacting execution time should be evaluated critically if it really needs to be user serviceable, or if it benefits to be done fast from the start.

I get that it is much easier getting new features implemented in a language that is more widely used and easier to grasp and I have nothing against that at all. "Make it Work, Make it Right, Make it Fast" in that order. Would be a shame to see features stuck at step 1 or 2, ignoring performance.
heda
Veteran
Posts: 1348
Joined: Sat Dec 12, 2015 5:49 pm

Re: Freecad fails to be serious CAD because of poor language choice

Post by heda »

it is still not clear to me how these points were made, as draft points or as a point-cloud.

anyway, when working with larger dxf files one can easily study the sluggish behaviour of fc.

if one imports as "simple part shapes" it is generally fast, and when choosing "draft objects" it is generally slow.
now the natural conclusion is draft is python so that is why it is slow, which of course has some merit to it,
about a year ago I had a use case which made me check if I could make the import a bit quicker, and basically with a one liner python code change I could get the import to be order of magnitudes faster (if I remember right I avoided recomputes to get it to go faster). So without any doubt there are some low-hanging fruit to be made on speed, but at the same time for the regular use seen here on the forum, finding speed ups like this is quite likely not to happen often, for the common use cases, imho speed has been looked into.

that aside, I think there is a potential to speed fc up in terms of treeview.
there seems to be a exponential slow-down with increased numbers in the root of the treeview, the same number of objects divided into groups/parts etc makes things go faster again - implying that it is not about the total count of objects, but rather how the treeview itself is organised.
the same behaviour can be observed if one works with large step assemblies.

if anyone wants to pick that up and investigate if anything can be done - I think that is a possible low hanging fruit for making fc appear to be faster in use cases where there are a lot of objects involved.

btw - always a pleasure reading abdullah's posts :-)
User avatar
Kunda1
Veteran
Posts: 13434
Joined: Thu Jan 05, 2017 9:03 pm

Re: Freecad fails to be serious CAD because of poor language choice

Post by Kunda1 »

heda wrote: Sun Jan 09, 2022 12:23 pm btw - always a pleasure reading abdullah's posts :-)
Agreed! It's a treat. And doubly so seeing wmayer weigh-in.
heda wrote: Sun Jan 09, 2022 12:23 pm if anyone wants to pick that up and investigate if anything can be done - I think that is a possible low hanging fruit for making fc appear to be faster in use cases where there are a lot of objects involved.
That's worth exploring. Also seeing what RT has done with treeview is worth studying as well.

So that leads me to acknowledge that wmayer did bring up the scenegraph:
wmayer wrote: Sat Jan 08, 2022 4:50 pm When you talk about 4000+ points how do you create them? Is each point represented by an own object in a document or do you create one object with all points. This makes the difference and not the chosen language. The bottleneck when creating an object for each point is the scenegraph because traversing it is very time consuming.
I think that is rich territory to explore as well.
Alone you go faster. Together we go farther
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
User avatar
adrianinsaval
Veteran
Posts: 5541
Joined: Thu Apr 05, 2018 5:15 pm

Re: Freecad fails to be serious CAD because of poor language choice

Post by adrianinsaval »

andremiv wrote: Sat Jan 08, 2022 11:43 pm After looking vaguely the occt kernel repo, the reputation and seriousness I am pretty confident (no offense) that the python is most certainly the problem and not the underlying occt kernel.
This is the most stupid way of determining that. People didn't tell you that OCC is the bottleneck just because, they've told you so because many functions have been profiled many times, I'll let you take a guess what the result usually is...
On the other hand you mention having a lot of points, the question is now why are you dealing with that many points for a gear? FreeCAD is not a mesh manipulation software, it uses a BREP based kernel.
Also because I used cloud compute program which also use occt and is way faster.
which one and are you really doing the same thing there?
Post Reply