You convinced me at 80%, I trust your expertise of the Freecad program but...You are still ignoring all the posts telling you that not Python is the bottleneck. So speeding up the Python stuff would not speed up the whole FreeCAD performance. It would probably speed up a rather neglectable part. And interpreting your C-like scripting language would make it slower too, wouldn't it?
the STL to brep converter in the part module is way too slow, I think there is a problem here. Was'nt able to identify the file that manage that on the freecad repo, I assume it would be in src/part but did not find it. Don't tell me it is the fault of the API for this one
A research on the API uses of binutils vs breputils suggest part of Freecad uses ascii brep. Am I right on this one ?
You don't interpret C like scripting language, you compile it and linked against it at run time, For instance, you could have a script that accept a valid C maths function to program points. Of course the user should not program in C, only enter the math functions and basis that generate points for a point generator script. Then this custom C script function is inserted in a template C file that is compiled then freecad calls it if compilation was suscessful, seems hard to do but not at all. Only require a gcc dependancy like python scripts need a python depandancy.
EDIT : To be clear it does'nt require restarting of the program, the compiled function can be called provided the compilation succeded, compilation should take less than one sec
EDIT 2 : It is not linked at runtime, wrong formulation, you load dynamically your "C script" generated object when Freecad is already running
EDIT3 : You use dlopen dlsym for linux and dllopen and getprocadress for windows