kbwbe wrote: ↑Thu Dec 19, 2019 7:50 am
Hi Turro,
there should be no changes in master branch which have slowed down the imports. Do you register that importing got slower or are you importing bigger shapes bigger than before ?
> Multiprocessing/Multithreading: May be better, i have to check how good this works with FC.
> C-code: Sure faster, but i have no idea about implementing it into FC.
Additional:
I am working on a big update within the devel branch. A2plus creates "xxx.a2p" files during importing of files. The files contain all resulting work of an import process (shape, colours, toponames) and speed up a second time import by factor 3-4.
Hi Kbwbe,
Yes I'm talking about complex objects with many curved surfaces which creates tons of faces.
by analyzing a2p_muxassembly.py it looks like the slowness is mainly caused by Part.Makeshell(faces), other iterations look such as creating the faces list so I don't expect a big improvement in parallelizing them. Am I wrong?
Regarding C code.... rewriting the workbench in C IMHO requires too much work compared to the benefit, it would be interesting writing complex calculation task in a .dll and .so and importing it in python, it could be helpful in replacing some numpy or placement complex iterations within the solver (if any).
threading across cores is quite easy in python, from
https://docs.python.org/3/library/multiprocessing.html
Code: Select all
from multiprocessing import Pool
def f(x):
return x*x
if __name__ == '__main__':
with Pool(5) as p:
print(p.map(f, [1, 2, 3]))