High computational complexity in `update_task_state()`
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
Research direction
Start by tracing update_task_state() into _evaluate_route() and the self.graph.in_cycle(task_id) call that invokes NetworkX simple_cycles(). Use the large-loop workflow example to measure the current behavior, then define a replacement that preserves route evaluation while avoiding the expensive cycle enumeration; completion should include evidence that scheduling remains correct and no longer takes tens of seconds.
Written by the indexing model from the issue text.
Description
Hello,
We've seen severe performance issues with some of our (larger) workflows, that we've tracked down to an expensive call to nx.simple_cycles() whenever a state transition happens: A task finishes, then the workflow engine takes in the order of tens of seconds (CPU bound) to process the next task to schedule.
update_task_state() is called whenever a task ends and the next one(s) need(s) to be decided. This makes a call to _evaluate_route() which then checks self.graph.in_cycle(task_id). The latter is a list comprehension around simple_cycles() from the networkx lib.
The complexity of that function is linear in terms of the number of simple cycles in the graph.
Unfortunately, for graphs with large loops, this number can be quite significant. In the following example (similar to some real-world workflows), it scales exponentially (against the number of tasks):
version: 1.0
input:
- can_do_task_a
- can_do_task_b
- can_do_task_c
tasks:
main:
action: core.noop
next:
- do: loop_begin
loop_begin:
action: core.noop
next:
- do: task_a
task_a:
action: core.noop
next:
- do: task_a_impl
when: '{{ ctx("can_do_task_a") }}'
- do: task_b
when: '{{ not ctx("can_do_task_a") }}'
task_a_impl:
action: core.noop # real action goes here
next:
- do: task_b
when: '{{ succeeded() }}'
task_b:
action: core.noop
next:
- do: task_b_impl
when: '{{ ctx("can_do_task_b") }}'
- do: task_c
when: '{{ not ctx("can_do_task_b") }}'
task_b_impl:
action: core.noop # real action goes here
next:
- do: task_c
when: '{{ succeeded() }}'
task_c:
action: core.noop
next:
- do: task_c_impl
when: '{{ ctx("can_do_task_c") }}'
- do: tasks_done
when: '{{ not ctx("can_do_task_c") }}'
task_c_impl:
action: core.noop # real action goes here
next:
- do: tasks_done
when: '{{ succeeded() }}'
tasks_done:
action: core.noop # real action goes here
next:
- do: loop_begin
when: '{{ failed() }}'
There is a small optimization that can be made (I will submit PR #273 ), but it's a band-aid solution that only works in some cases.
Is there a way to remove the need for that call entirely?
- Dominant language
- Python
- Stars
- 111
- Forks
- 44
- PR merge metrics
- No merged PRs in 30d
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from StackStorm/orquesta
-
Difficulty 3/5 1-2 days Newbie friendliness 48/100
StackStorm/orquesta#275 ·
-
Difficulty 3/5 1-2 days Newbie friendliness 35/100
StackStorm/orquesta#274 ·
-
Difficulty 3/5 1-2 days Newbie friendliness 45/100
StackStorm/orquesta#268 ·
-
Vague error Open
Difficulty 2/5 1-3 hours Newbie friendliness 45/100
StackStorm/orquesta#265 · 1 comment ·
-
task with join: all starts without waiting for all the previous task completed when there is a loop Open
Difficulty 4/5 3-5 days Newbie friendliness 35/100
StackStorm/orquesta#263 ·
All issues in StackStorm/orquesta
Similar issues
-
documentation help wanted
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
simonw/sqlite-utils#872 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100