Thanks a bunch for looking into it, the effort as well.
It’s good to know they’re aware and it will likely be uncapped eventually. The issue itself being complex and/or difficult to change is understandable, though not the best news for some.
Glad to hear this is being heard somewhere, scaling workers with CPU cores would be great to see but it’s a bit concerning that there’s nothing further on fixing this issue in the meantime. This issue is actually just a FastFlag setting (DFIntRuntimeConcurrency). Changing it works as expected, setting it to 8 resulted in 8 worker threads, and very large numbers seem to already get capped by the engine.
According to the FastFlag tracker, the flag was created in June last year (set to 2), then raised to 3 in October. I don’t think the limit worked properly around this time, as I remember having 8 workers in the client in October. It seems that this was fixed (unfortunately…) sometime in November. Then, on March 18th, the flag was set to be platform specific, although for some reason this change left PCDesktopClient and MacDesktopClient at 3 despite Studio being set to 8 on the same platforms.
Would it be possible to raise this value before the new core-based worker allocation is available? This is genuinely crippling for quite a few experiences (and has been for months now), which is very frustrating when it’s just a FastFlag setting.
1 Like
Thank you very much for getting word on this; it means a lot for you to ask about internally to see what’s going on so we can get a glimpse and anticipate the trajectory of a certain feature.
While unfortunate (yet understandable) that there’s no concrete dates, at least now we know that the worker count will eventually be tied to the host’s core/thread count.
This will give me motivation for working back on my renderer, knowing that the required performance will be possible in the not-so-distant future.
Thanks!
1 Like