Repository navigation
Perf/decision task - #1050
Perf/decision task#1050marco-c wants to merge 3 commits into
Conversation
Merging this PR will not alter performance
Performance Changes
Comparing |
|
wahou |
|
@codspeedbot run the new benchmarks against the base of pr, and display the performance changes with the head of the PR, with the link to the corresponding CodSpeed compare runs page |
1 similar comment
|
@codspeedbot run the new benchmarks against the base of pr, and display the performance changes with the head of the PR, with the link to the corresponding CodSpeed compare runs page |
Only members of the |
|
@codspeedbot run the new benchmarks against the base of pr, and display the performance changes with the head of the PR, with the link to the corresponding CodSpeed compare runs page |
I ran the PR's benchmark suite ( Compare runs page: https://app.codspeed.io/taskcluster/taskgraph/compare/6ab631c04cedfe38851b4dfa..6ab6348ca84b5010809f92e6 New benchmarks (base → head)
Existing benchmarks, same pair of runs
The other 17 benchmarks ( How to read these numbers
I didn't change anything on the PR branch. Summary
Was this response helpful? React with 👍 or 👎 to help us improve CodSpeedBot. |
|
Hey @marco-c, @JohanLorenzo, the correct compare page URL is: https://app.codspeed.io/taskcluster/taskgraph/runs/compare/6ab631c04cedfe38851b4dfa..6ab6348ca84b5010809f92e6 |
create_tasks rescanned every not yet submitted task each time a createTask call completed, rebuilding its set of dependencies and checking whether their futures were done. This is quadratic in the number of tasks, and runs on the main thread while holding the GIL. It also recursed once per completed batch, so a dependency chain of a few thousand tasks raised RecursionError. Now the number of pending dependencies of each task is computed once, and decremented as dependencies are created. A task is submitted as soon as its count drops to zero. As before, tasks depending on a task that failed to be created are not submitted. With createTask mocked out, creating a 20,000 task graph takes 1.9s instead of 6.2s (binary tree) and 2.0s instead of 4.6s (fan-out/fan-in).
To decide whether a task can be replaced, replace_tasks computes the latest deadline of its dependents. It resolved the deadline of every dependent for every task, although tasks such as docker images or toolchains share thousands of dependents. Now each task's deadline is resolved at most once, relative to a single `now`. Similarly, IndexSearch parsed the same deadline (and the expiration of tasks used as replacement for multiple tasks) over and over, so parsed timestamps are now cached. On a synthetic graph of 20,210 tasks where the 210 build and docker tasks are replaced, replace_tasks takes 0.17s instead of 0.24s.
Before loading a kind, the generator filtered all the tasks loaded so far to find the ones belonging to the kind's dependencies (copying them first when loading kinds in parallel). This is proportional to the number of kinds times the number of tasks, and in parallel mode it happens on the main thread, delaying the submission of newly unblocked kinds. Now loaded tasks are also grouped by kind, so the tasks of each kind dependency are looked up directly. They are still passed in the order in which kinds were loaded. With 150 kinds of 270 tasks each (40,500 tasks), each depending on three other kinds, gathering the kind dependency tasks takes 0.01s in total instead of 0.42s.
55031b8 to
7c4a13b
Compare
I haven't yet reviewed all the commits, I'll probably drop some of them, but I want to see if codspeed picks anything up.