I ve noticed, that in higher res builds expander takes by far most time in compare to other devices (even flow restructure, erosions, create water etc…). I would expect times simular to blur. No issues in low res:
This simple layout generator killed expander for 12 minutes (8k). Interesting is, that in 2k it takes 2.8 seconds:
Expander node is still single threaded at the moment, so the performance depends on your single core’s base clock.
The expander should be approximately the same level of performance as the Blur device set to “Precise” mode with a kernel of the same size. I haven’t investigated yet if the same kind of algorithmic enhancement can be applied to the expander as is done with the approximate blur. Without that, it scales sub-linearly with increasing resolution, so its unfortunate but not surprising to hear that it starts dominating build time at high res.
The Expander is fully multithreaded, so if you’re running into a situation where it’s not using available cores there’s some kind of issue there…!
It is running full multithreaded (32 in my case), I didnt tell it didnt 
2k - 2.8 seconds, 4k 25 seconds, 8k this time cca 10 minutes. Preparation phase was something like 9:50. So this single device + other expanders are taking more than 1/2 of whole 8k build (many erosions, water, etc, cca 100 devices):
Apparently the issue on my end is that the cores are being parked with some filter devices that take too long to prepare. Could be some customizations I did to my machine recently. I’ll investigate more.
Edit: Yep, all devices that take longer than 5 minutes to prepare, are building single core after that. Multithreading is restored on the next node. It’s my own machine, will have to reset some registry tweaks I made.
The primary focus right now is getting LTE ready for release, but I’ll definitely put this on the list of things to look next! The Expander is a very useful device and I’d certainly like to improve its performance in situations like this. I also ran across an interesting research paper a month ago that promises a method to restore the “Circular” kernel type, which has always been useful but was even more prohibitively slow.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
