Sketcher performance - why is Python the culprit?

[acolomitchi]

Why is the sketcher relying so heavily on Python, to the point of CPU time in Python versus Sketcher's Solver are in a > 400:1 ratio?

(code sync-ed from github master yesterday)

Code: Select all

OS: Windows 10 Version 2009
Word size of FreeCAD: 64-bit
Version: 0.21.0.31333 (Git)
Build type: Release
Branch: master
Hash: 3a4d2399d0facaee1516212b1df9e9b97dd8f3a0
Python 3.8.10, Qt 5.15.2, Coin 4.0.1, Vtk 8.2.0, OCC 7.6.3
Locale: English/Australia (en_AU)
Installed mods: 
  * CurvedShapes 1.0.4
  * freecad.gears 1.0.0
  * lattice2 1.0.0
  * sheetmetal 0.2.59

To repro:
- Win/Visual Studio Community 2022 - set the FreeCADCmd as the startup project. Build the "Release" configuration.
- add the attached "solverLoad.py" as a cmdline arg for the "Debug settings" of the project
- go to menu "Debug/Performace profiler..." (Alt-F2), pick the "CPU" metric and hit the "Start" button at the bottom
- takes about 4-5 minutes to get the report (I used a laptop with AMD Ryzen 5 3500U 2.10 GHz, 16 GB RAM)
- once the execution is finished and you get the report, click the "Open details" link (under the plot) and set the current view to "Module".

solverLoad.py

(2.74 KiB) Downloaded 51 times

My report shows something like this:

PerfReport-FCCmd.png (66.53 KiB) Viewed 1683 times

The script creates a sketch with 137 elements (an ellipse and LineSegs for the rest) and 400-ish constraints - about 40 are redundant (constructing a tangent just to construct the normal on its base rather than straight in the ellipse, but I wanted as many constraints as possible with little imagination and coding effort). Once constructed, one of the primary driving constraints (the angle of the ellipse's major axis with the X one) is modified, just to make sure I'm kicking the solver into action on the entire set of constraints.

To me, that's mind-boggling. I mean, 137 elements represent some 500+ DOFS.
I was expecting that solving such a big multi-dim equation within so many constraints to eat most of the CPU. But... surprise...
Why, oh, why? Have I done something wrong and didn't hit the solver as hard as I imagined? Is there an issue with the design/impl of the Sketcher?

[chrisb]

I'm not sure if creating a sketch with errors is really representative, and if not the solver ends its work prematurely in this case. We know from the GUI, that continuing without fixing an error, often yields the whole sketch completely useless up to a state where even removing all constraints including and after the first erroneous one doesn't help.
To be representative I'm afraid you have to invest more effort into the sketch.

[GeneFC]

Why is the sketcher relying so heavily on Python

I am not sure what you are trying to say.

Sketcher is coded almost entirely in C++. There are only a very few Python modules, mostly for testing.

All of FreeCAD needs to be consistent with the overall strategy of mixing C++ and Python, so Sketcher needs some code that supports this requirement.

I think the entire problem is due to your testing method.

Gene

[adrianinsaval]

I don't if the solver even runs if the sketch is so overconstrained, are there no errors raised when you run your macro? btw you don't need a body at all if your purpose is just to stress test the solver, I don't think it has any effect.

[acolomitchi]

(note the reply subject change)

To be representative I'm afraid you have to invest more effort into the sketch.

Took a bit, but here it is

solverLoad-2oo.py

(4.13 KiB) Downloaded 58 times

- 201 elements, 568 constraints, sketch fully constraint with no redundants over over-constraints.
- the running time of the solverLoad-2oo.py script is about half of the one of the solverLoad.py initially used (the one with partially redundant constrains). I infer that the solver detects the (partially) redundant but continues to use them

The ratio of CPU time reported against Python vs against sketcher is lower
But still the CPU time reported against Python dwarfs the one of the sketcher. Why?
What does python have to do with the constraint solving process?

PerfReport-FCCmd-solverLoad2oo.png (37.8 KiB) Viewed 1468 times

PS:

I'm not sure if creating a sketch with errors is really representative, and if not the solver ends its work prematurely in this case.

Minor grumbling: unlike "over/contradictory constrains", partially redundant constraints aren't quite errors, more of a warning of non-optimal definition of constrains. Based on the Solver Architecture booklet on page 9

The presence of redundant solver constraints means that the solver has linearly dependent relations, equations, rows in the matrix. As a consequence, it is obvious that the number of degrees of freedom will no longer be determined by the difference between the number of paramaters and the number of constraints.

That means the solver will continue solving instead of bailing out.

[acolomitchi]

Why is the sketcher relying so heavily on Python

I am not sure what you are trying to say.

I'm seeing disproportionate CPU time reported by the VC++ profiler for execution of code in Python vs the "sketcher" module.
I don't understand why but if the above is not an artifact of my measuring process, there may be some corrections to improve the "sketching" experience in FreeCAD

I think the entire problem is due to your testing method.

Any suggestion that you can offer as to what the issue with my testing method is, please?

Thank you,

adrian

[acolomitchi]

I don't if the solver even runs if the sketch is so overconstrained, are there no errors raised when you run your macro?

Just the "partially redundant" constraints (which is a different situation from "overconstrained" - which signal contradictory constrains that are impossible to meet)

btw you don't need a body at all if your purpose is just to stress test the solver, I don't think it has any effect.

Oh, well, what can I say? I have a weakness for full-bodied sketches.
Glad to hear it doesn't impact the solver loading.

[chrisb]

What happens if you just change after building the sketch one of the dimensions. This should restart the solver but avoids all the creation stuff where python is involved.

[acolomitchi]

What happens if you just change after building the sketch one of the dimensions. This should restart the solver but avoids all the creation stuff where python is involved.

I adjusted just an angle of the major axis of the "support ellipse" (on which the entire geometry is computed), and that step resulted in an instantaneous resolve, the sketch was/is fully constrained before I adjusted it.
The "instantaneous" is in terms of my human-senses profiling, happened when I tested the functionality of the script in FC GUI. And I did that adjustment via setting the datum of the specific constraint, but I did it using the script console.

I assume you are suggesting the first resolves happen when the constraints are added by the python script and so I should profile a change that is not triggered by python, is that right?
If so, is using FC GUI bypassing Python when effecting some changes?

[chrisb]

I assume you are suggesting the first resolves happen when the constraints are added by the python script and so I should profile a change that is not triggered by python, is that right?

No that's not exactly what I meant. I'm afraid that adding the geometry from Python is what takes most of the time here. I don't know what triggers the solver when adding stuff from python, i.e. if the solver starts after addition of each constraint, or only at the end.

What you should definitely do, if you want to see how the solver performs, is to separate the creation of the elements from the constraints.