Techdraw performance issues

[ToniTen]

Obligatory FreeCad information

Code: Select all

OS: Ubuntu 18.04.5 LTS (XFCE/xubuntu)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.24291 (Git) AppImage
Build type: Release
Branch: (HEAD detached at 0.19.2)
Hash: 7b5e18a0759de778b74d3a5c17eba9cb815035ac
Python version: 3.8.8
Qt version: 5.12.9
Coin version: 4.0.0
OCC version: 7.4.0
Locale: Spanish/Spain (es_ES)

CPU is a Intel Core i7-3770 CPU @ 3.40GHz, system has 32 GB of RAM

I'm experimenting some severe Techdraw performance issues. I work with medium size assemblies (Assembly3, FreeCad file weights around 5 MBs, STEP file of the assembly weights around 25 MBs), from parts that I either get from manufacturers as STEP files or design myself. I understand that sometimes the Step files from other programs are not 100% good, but they seem to work no problem with other CAD programs such as Solid Works. I am not in position to share the problematic assemblies right now (as they contain information that should be be revealed outside of my workplace), but I will see if I can make a test file that shows the problem.

Right now, my issues are as follow:

• Creating the first projected view takes a couple of minutes. Cursor changes to show that the program is working.
• Creating a section preview takes around 30s. This happens every time any parameter on the section view is changed. Cursor changes to show that the program is working, but returns to normal halfway through the process, even if the process is still ongoing and the UI is unresponsive. There is no way to stop preview creation as you change multiple parameters such as view direction, section plane position, etc, meaning that each change to these takes over half a minute.
• Confirming that preview and turning it into a section view takes the same amount of time as making a preview did.
• Exporting the page (with two projected views and one section view) to SVG for final touchup work in Inkscape takes 10+ minutes. At no point of the export is any visual indicator of the progress visible, not even a cursor change, and the whole UI is unresponsive
• After saving the file, opening it again takes 10+ minutes again
• Task manager only shows one core being 100% used, meaning that UI, geometry kernel and file output are done in a single thread. Memory usage is around reached 900 MBs or so.

I don't know about the internals of FreeCad or TechDraw within FreeCad, but some things seem evident to me (Please correct me if I'm wrong):

• Section view previews are not catched, meaning that when you accept and build the final section view, it gets redrawn from scratch, despite being identical to the final preview
• Export to SVG seems to require re-projecting all geometry, and re-creating all derived views, instead of turning what is visible in TechDraw into an output file
• Opening the file again requires recomputing all projections

I can see some possible improvements (don't know how straightforward they would be, since I know nothing about the architecture of FreeCad or of the workbenches, and assume that operations can't be easily split into multiple threads)

• Add a toggle to disable live preview so you can change the section parameters without triggering a redraw
• Cache section preview of a section view so confirming a section preview and showing the final section view takes basically no extra time.
• Cache Techdraw projections so they don't have to be rebuilt from scratch on file reload.
• Split the UI into it's own separate thread, so it remains responsive at all times (unrelated to TechDraw)
• Split projection into TechDraw into separate thread. Leave a placeholder while it's working
• Split export into a separate thread
• Delegate re-projecting them to separate threads that work asynchronously when something from the model changes

[user1234]

Hello!

I understand that sometimes the Step files from other programs are not 100% good

Make Geometry checks before use them. The OCCT kernel is very picky on crappy geomeries.

After saving the file, opening it again takes 10+ minutes again

This seems a regression i have seen earlier. FreeCAD recreates the drawing. As far as i know this behavior was solved.

Task manager only shows one core being 100% used, meaning that UI, geometry kernel and file output are done in a single thread.

Have you ever used other (commercial) CAD programs? If not then this hint: there is no CAD program that uses more than 1 CPU. The only exception i know is FreeCAD on boolean operations (with tbb).

Greetings
user1234

[ToniTen]

Hello!

I understand that sometimes the Step files from other programs are not 100% good

Make Geometry checks before use them. The OCCT kernel is very picky on crappy geomeries.

The problem is, what if they present issues? I can't control what manufacturers make available for download on their sites, and they aren't going to listen to a small fly like the company I work at, much less an individual. FreeCad doesn't give me any way to fix those geometries on imported STEPs for things like motors.

After saving the file, opening it again takes 10+ minutes again

This seems a regression i have seen earlier. FreeCAD recreates the drawing. As far as i know this behavior was solved.

Good to know that this is at least an known issue that had at some point a fix. What do I need to do to point someone with the appropriate knowledge to the issue so they can track the regression?

Task manager only shows one core being 100% used, meaning that UI, geometry kernel and file output are done in a single thread.

Have you ever used other (commercial) CAD programs? If not then this hint: there is no CAD program that uses more than 1 CPU. The only exception i know is FreeCAD on boolean operations (with tbb).

I don't expect the geometry kernel to be multi-threaded, but the UI should live in a separate thread from everything else at the very least. If possible, there should be a way to have each FreeCad document spawn a separate OCCT kernel to handle its geometry, meaning you can leave FreeCad working on one file, while doing something with another file. Browsers used to be single threaded, and then the paradigm shifted to have each tab be handled in a separate thread, while the UI is drawn in a separate thread altogether. Sure, memory use exploded, but even a Raspberry Pi 4 B has between 2 and 8 GBs of RAM right now, so we shouldn't restrict a CAD application to work with ram amounts common 10 years ago.

[user1234]

The problem is, what if they present issues?

Recreating. That is normal (not only for FreeCAD).

I don't expect the geometry kernel to be multi-threaded, but the UI should live in a separate thread from everything else at the very least.

That sound easy, but it is quasi impossible. Also there is no CAD program (i know) that can handle that (except with with remote updating, but then you also 2D only and you can not work on the same model, and need extra licenses and extra servers). But you can open more than 1 instance of FreeCAD and work on more models on the same time. When one part is refreshing, you can work on an other instance of FreeCAD on a other model.


Greetings

[enakcm]

I think this issue could be improved, if "keep updated" was off by default. Then there could be an option to only redraw one view, not the whole page. That could help a lot of the performance issues.

Additionally, I found here on the forums that setting data -> projection -> perspective to TRUE helps speeding up the process a lot. Just set data -> projection -> focus to a high value (e.g. 100 m = 100000 mm in my case) and you get a quasi-non-perspective projection.

[Haldar]

Hello I am also experiencing performance issues and i have a stupid question.
ToniTen talked about the multithreaded pages but what about that some of the rendering/calculation of the HLR were done by the GPU (hardware aceleration) is that possible?

[wandererfan]

Thanks for your comments. Here are some thoughts on some of your points. Sorry about the formatting...

Creating a section preview takes around 30s. This happens every time any parameter on the section view is changed.
WF>>> this used to work differently - the parameters could be changed at will and the graphic was only updated on the "OK" button. It was changed due to complaints that parameter changes were not immediately reflected in the graphic. It seems somebody is going to be unhappy either way.

Confirming that preview and turning it into a section view takes the same amount of time as making a preview did.
WF>>> Making a "preview" is the same amount of work as making the final view, so it takes the same amount of time.

Exporting the page (with two projected views and one section view) to SVG for final touchup work in Inkscape takes 10+ minutes. At no point of the export is any visual indicator of the progress visible, not even a cursor change, and the whole UI is unresponsive
WF>>> is the 10+ minutes for an export longer or shorter than a regular recompute and redisplay? The actual process of writing the graphic to an SVG file is fairly fast, there might be a superfluous recompute happening.

After saving the file, opening it again takes 10+ minutes again
WF>>> the main app saves geometry as brep files to save time at load time. It might be possible to do something similar for drawings.

Task manager only shows one core being 100% used, meaning that UI, geometry kernel and file output are done in a single thread. Memory usage is around reached 900 MBs or so.
WF>>> can't fix this within TechDraw. FreeCAD's design "single threaded" and OCC is not, in general, thread safe, so this is unlikely to change in the near term.

Add a toggle to disable live preview so you can change the section parameters without triggering a redraw
WF>>> KeepUpdated property at the Page level will suppress updates. There is also a preference setting on the General tab to make this the default behaviour.

[wandererfan]

I think this issue could be improved, if "keep updated" was off by default. Then there could be an option to only redraw one view, not the whole page. That could help a lot of the performance issues.

Additionally, I found here on the forums that setting data -> projection -> perspective to TRUE helps speeding up the process a lot. Just set data -> projection -> focus to a high value (e.g. 100 m = 100000 mm in my case) and you get a quasi-non-perspective projection.

There is a preference for the default value of KeepUpdated on the General tab. A View level KeepUpdated property is definitely something to look into.

Using the perspective projector can speed things up sometimes, usually when there are geometry problems. Sometimes the regular (orthogonal) projector works better.

[wandererfan]

Hello I am also experiencing performance issues and i have a stupid question.
ToniTen talked about the multithreaded pages but what about that some of the rendering/calculation of the HLR were done by the GPU (hardware aceleration) is that possible?

We don't own the HLR code, so our options are limited. Doing HLR requires many intersection operations and it seems like a problem that would respond to parallelism using either CPU or GPU.

We did ask OCC about modifying the HLR code to perform the intersection calculations in parallel, but they were not interested unless we wanted to pay for it. To be fair, they are in business to make money and the algorithm behaves reasonably on good geometry.

[Haldar]

Hello I am also experiencing performance issues and i have a stupid question.
ToniTen talked about the multithreaded pages but what about that some of the rendering/calculation of the HLR were done by the GPU (hardware aceleration) is that possible?

We don't own the HLR code, so our options are limited. Doing HLR requires many intersection operations and it seems like a problem that would respond to parallelism using either CPU or GPU.

We did ask OCC about modifying the HLR code to perform the intersection calculations in parallel, but they were not interested unless we wanted to pay for it. To be fair, they are in business to make money and the algorithm behaves reasonably on good geometry.

As i use a lot of bodies when I am working, due to some mechanical design, I feel that the workaround for the moment is using the draft dimensioning instead and then use arch section view or something like that.