OK, I thought that meant one component (“SolveInstance”).
Yup, that’s very typical for any complex network. But it’s up to the designer of the solution to avoid them, with different approaches. Some of them are simply going to be The bottle neck, while others can be avoided.
But especially with user interactive processes not only total processing speed is relevant, also responsiveness, sometimes even to the cost of total processing time.
I’m also thinking about GH_FBP as a “general processing platform” and there are endless kinds of cases which requires different approaches to perform as desired.
That depends entirely on the problem. In many cases, yes, and I know that not all understand the point with “traffic lines” which is not so much parallel as dynamic serial (faster car’s can pass each other, which avoids slowing down the whole, etc).
But when thinking in terms of a manufacturing plant it is inevitable that in many cases you really do want to process material in multiple production lines even using complex machines ( = Components).
Very tight loops with very many items and small operations is of coruse best processed internally in components, but that’s of course not always the case.
And the main point really is to let the end user design his own production lines (component sequences) in his own manufacturing plant (solution) using the various techniques for queing, load balancing etc which - and you already hinted about (“Task-Parallel-Library is really good at;”) - requires planning ahead depending on the data you are processing. (this is why the task-parallel-library consist not only of one scheme…)
Which is exactly why not all cases will be handled very efficiently in “fixed scheme components”, but would benefit from the user’s own design of the overall process flow.
Anyway, from start I have dreamed of seing GH making this possible on this very platform. That would make GH a killer app for “any kind” of massive data processing. Unix pipes comes to mind (but even more flexible than that).