UserInterface__buildHTMLForOS is quite far up on profiles, especially getSortedResults. So maybe keeping a sorted list of results in the first place and using insertion sort on updates is better than doing a qsort on every redraw. I will investigate further tomorrow.

So instead of doing a sort on every draw, I do an insertion sort when adding the result. Also, I got rid of the `order` handling in UserInterface and pushed that to Data as well. It’s still ugly, but its in a better place now. According to chromes profiler, this gets us from ~300ms down to ~70ms, a ~4x speedup :-) (that vs production, so includes the patch from yesterday)

Comment on attachment 816803 [details] [diff] [review] buildhtml.patch Review of attachment 816803 [details] [diff] [review]: ----------------------------------------------------------------- lgtm and initial testing comparing prod with repo tip (but with b2g desktop changes backed out), showed identical sort order across 5 different trees. Thank you for this! \o/ :-)

And can you actually notice some improvements? Like less jank/hangs when updating?

Yeah with this and the other patches, it is very noticeable. eg: View mozilla-central, press down arrow two times, open the filters menu, enter "opt" in the job name box, hit enter and see how long for UI to respond (easiest way is to watch the location bar to see when the param updates). Rough timings take it from 4.5s to 1.5-2.0s :-)

Thats good to know. I might have found another inefficiency to further speed this up :-)

In production :-)