Filing this after the discussions we had at the work week. Breaking out of bug 1059286, since it's easier to keep one issue per bug (and that bug caused a regression, so will require more back and forth).

Making the summary a bit more general, since this bug has turned into the meta bug for overall UI perf/responsiveness issues.

Making this a P2 since the next actionable bug is bug 1125229, which is a P1.

@sheriffs: This meta-bug is on the sheriff top issues list on the Treeherder meeting etherpad, however to make this more actionable (and so we know we're spending our time on the right perf issues), it would help if you could list which specific workflows are slow, so we can profile those? If you could file a new dep bug for each one, that would be awesome :-) Once we have those bugs filed, if you could pick the most urgent of them and add to the meeting etherpad - we can take a look :-) (Needinfoing a few people individually, since I can't needinfo the sheriffs alias - but everyone else watching the alias is welcome to do the above too :-))

I think bug 1076840 and bug 1164266 would help immensely with perceived and actual performance. While not something I commonly do, clicking the "load 50 more" button does lock up my browser for several seconds unless I'm on a beefier system. I'm wondering if there's some way of offloading the more intensive parts of fetching 50 additional sets of jobs that doesn't lock everything up until it finishes processing all of that new job data?

(In reply to Wes Kocher (:KWierso) from comment #6) > I think bug 1076840 and bug 1164266 would help immensely with perceived and > actual performance. This doesn't really answer the question of what workflows you're finding slow. :) Bug 1076840 has to do with initial and subsequent resultset loading performance. Are you saying that's still too slow for you? Bug 1164266 touches the same stuff, as well as update performance (which would probably be perceived as jank after the result sets are fully loaded). Are there still issues there as well? > While not something I commonly do, clicking the "load 50 more" button does > lock up my browser for several seconds unless I'm on a beefier system. I'm > wondering if there's some way of offloading the more intensive parts of > fetching 50 additional sets of jobs that doesn't lock everything up until it > finishes processing all of that new job data? I believe we've talked about doing this, most of the overhead just comes from inserting tons of elements into the DOM, which is rather unavoidable. It might be possible to do the JSON parsing in a web worker and post results back when done, which might solve some of the jank -- though I'm not sure it's worth the increase in complexity. I suspect not.