I see this came up before and resulted in RH-43240 … I’m finding that I could very much use that!
In the absence of multithreaded geodesic, anyone have thoughts on optimizations that I could consider? My application is getting geodesic lines between ~34,000 start points and 5 end points (about 170k lines total). Anything I should consider doing to the surface or endpoints to improve performance?
Maybe you should consider using multithread anyway.
A linear c# non-multithread script with the Surface.ShortPath calls do the work exactly like native Geodesic block.
As expected, the multithreaded version takes about 12% of the time to finish the same task, in my system.
Ryzen 1800X , 8-core 16-thread; 100/8=12.5 … i’d say it is scaling pretty good.
To make the script work fast, multithreaded, it loads the parameters as lists.
Grafting will probably work differently now, in terms of speed, time and results
Maybe you’ll want to use Cross Reference block before or to edit the code inside the script.
Also, the script consider P0 and P1 lists having the same length. If you graft, you’ll need to use longest list before, as here:
Hope it helps!
If you are on an octa-core you’ll maybe pass from 36m to 5ish minutes …
Let me know, I’m curious now!
That’s a great idea… thank you for the idea and starter script. I will play with it and report back!
@maje90 Yep, that worked beautifully. For some reason the c# script outputs a tree with one more branch than the geodesic component, but that’s easy enough to address.
At the moment I only have a quad core procesor, so times dropped from 35 minutes to 8.5 minutes. So your solution, while awesome, may end up being very expensive indeed if it tips me into upgrading to 8 / 16 / 32 / 64 cores.