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?
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.
Note:
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:
@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.