Freecad fails to be serious CAD because of poor language choice
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
Re: Freecad fails to be serious CAD because of poor language choice
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
Greetings
user1234
Re: Freecad fails to be serious CAD because of poor language choice
Export desmos as SVG.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.
Import SVG in FreeCAD.
Extrude it.
- Attachments
-
- desmos.png (21.77 KiB) Viewed 2124 times
- 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
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.
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.
Re: Freecad fails to be serious CAD because of poor language choice
Macros? Easy workbenches?....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,
Re: Freecad fails to be serious CAD because of poor language choice
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.
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.
Re: Freecad fails to be serious CAD because of poor language choice
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.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 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.
- 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
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.
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.
Re: Freecad fails to be serious CAD because of poor language choice
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
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
Re: Freecad fails to be serious CAD because of poor language choice
Agreed! It's a treat. And doubly so seeing wmayer weigh-in.
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:
I think that is rich territory to explore as well.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.
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
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
- adrianinsaval
- Veteran
- Posts: 5553
- Joined: Thu Apr 05, 2018 5:15 pm
Re: Freecad fails to be serious CAD because of poor language choice
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.
which one and are you really doing the same thing there?Also because I used cloud compute program which also use occt and is way faster.