Comment 5 for bug 1469873

It's a weekly (People) that some locations have back to 2013. It's slightly inflated in that some of them come from merged records and some duplicate parts need to be merged away, but roughly 3 years worth of weeklies is over 150 so it won't likely come down significantly.

The issue appears to be dojo specifically. I profiled it building the list in Chrome and I'll attach a screenshot. For anyone following along that hasn't messed with Chrome's JS Profiler, the Y axis is time (from 0 ms to about 1.8 mins ) and the X axis is the stack depth, so the taller the graph the more calls are being made until something "finishes" and returns back up to a high enough level to repeat everything for the next part (when the graph goes to 0 no JS is running), and the color bars at the bottom show the functions called between the two vertical bars in the top graph.

You can see the peaks where new rows are inserted start to separate at around 16 seconds* on this run and they're quite far apart near the end around the 1.7 min mark (on a 3GHz Xeon E5-1607 with 16GB of RAM). dojo.declare.updateRowCount start around 6 ms for the first row and is taking 1.34 seconds between rows at the highlighted point on the graph. I don't think there's anything that can be done in Evergreen except either make that interface page (makes merges harder) or wait until dojo is out of this interface (which isn't in the cards right away since this is an interface that can be run as-is in the web client).

If there's any other data that would help to have let me know. If anyone is curious about the database, it only took 535ms to return these parts.

* this is not 16 seconds from the initial return of data, I had to login first which pushed things back 7-8 seconds.