Pipeline Graph: Addressing Size Comprehensively
Let's create a holistic plan to address pipeline graphs of larger size.
We have an ongoing series of issues, backend and frontend, relating to larger graphs.
On the backend, this can be seen mostly in terms of bug reports on N + 1
-related behavior (#299848 (comment 637216455), #330707 (closed), #323213 (closed), and #335791 (closed)) and other conversations related to job numbers.
On the frontend / in UX, it manifests in terms of an ongoing stream of discussions to decide what to do on an ah-hoc basis (see #330071 for one example).
Spanning the both, it activates discussions of where to do certain calculations: #332274
We can see from all the issues that these seems disparate, but they are all linked by the theme fo big graphs. So let's make this a focus and have an ongoing plan.
Suggested Plan
-
Collect data about graph size in general (we have some of this but could improve it) -
Identify a handful of indicative measurements (loading a graph of M size with N running jobs, link hover performance, other things I have not thought of) -
Create an ongoing project to identify and fix query timing (one N + 1 a milestone?) -
Identify and address UX concerns holistically
Edited by Sarah Groff Hennigh-Palermo