Yeah, good point. Actually, 1000 processes completed very quickly. 5000 wasn’t bad but performance degraded rapidly from there. I’ll be looking at refactoring some. I wonder how I can determine whether performance is degraded due to a bottleneck?
Thanks
I think he means create ServiceTask, JoinTask etc. modules that have functions like create_new and complete_task.
Consider using case instead of a series of if statements or a cond (see execute_process) that checks the same key a dozen times.
You’re discarding the state on line 282 there aren’t you?
Instead of checking type everywhere, you’d define a single map:
@callback_modules %{
decision: DecisionCallbacks,
service: ServiceCallbacks,
send: SendCallbacks,
...
}
A method like complete_able simplifies to:
defp complete_able(t) do
@callback_modules[t.type].complete_able(t)
end
DecisionCallbacks then defines:
defmodule DecisionCallbacks do
def complete_able(_task), do: true
...more functions used elsewhere in ProcessEngine...
end
This would also be a valuable place to utilize a behaviour to ensure that the callback modules implement a consistent interface.
A further, even more dynamic approach, would have a field on Task that contains the callback module name. That would allow tasks with the same type to have different callbacks. Whether that’s a bug or a feature will depend on your specific needs 
One general note about both variants: they make the code easier to read, but also obscure it from parts of Elixir’s static analysis.
For instance, you would get a compiler error if you wrote DecisionCallbacks.complete_able() (calling with the wrong arity) explicitly, but writing @callback_modules[t.type].complete_able() will only crash at RUNTIME.