App and grain list are surprisingly slow to display

[kentonv]

When clicking on the app list or grain list tab, there is a noticeable pause before the content actually displays. No network communication appears to happen during this time, therefore it would seem that we're managing to chew up a lot of client-side CPU. I bet it could be easily optimized.

[ocdtrekkie]

I am super happy this is being paid attention to.

[zarvox]

While I've not profiled anything, an obvious piece of CPU-related low-hanging fruit would be caching generated identicons.

[paulproteus]

On my laptop, this is about 3 seconds to load /grains when I reload.

@kentonv what sort of performance do you experience, and what sort of numbers would you like to see?

Same question for @ocdtrekkie .

[ocdtrekkie]

I'm getting about 2 seconds on /grain (Asheesh, "grains" plural is a 404 for me.) My comment was more a general statement that this sort of thing be carefully watched, to avoid the 12 second page load horror of the old Google+ interface, which I suffered under greatly around when this topic was brought up. ;)

I would say that for a list of files with small icons, it seems like a long load time. Realistically though it is not bad at this time. I would be worried if it got longer.

[zarvox]

I'd be curious to know the time breakdown - there's a chunk from network traffic, fetching subscriptions for Grains and Packages and ApiTokens, and then there's a chunk from CPU (loading, doing joins, sorting, generating identicons, rendering DOM).

I'd like to know which of those two dominates the time-to-useful-render. If it's network IO, then we'd want to see if we can get pagination or transfer data more efficiently or something. If it's CPU time, then we'd want to look into optimizations and if there are more efficient ways to express the work to be done.

[kentonv]

The bug report here was not about reloading, but rather rapidly flipping between "apps" and "grains". There is no network traffic taking place, yet it takes almost a second to flip. I would expect this to be instantaneous.

[zarvox]

So, I spent some quality time with Chrome's timeline tool, and the vast majority of the time was spent in callstacks which were mostly Blaze's internal functions, along with a decent chunk of jquery setting up/tearing down a bunch of event handlers. Application code, as far as I could find, was a pretty-small fraction of the render time - less than 10% of the render time was from the filteredSortedGrains template helper, which does all the sorting/indexing/mapping-to-data for the page.

As a sidenote, it's really tiring to read the profiles since there's basically no application-level context, and there's no annotation for "what template did this come from" and it's all minified on Oasis and I don't have sourcemaps.

So my takeaway is that Blaze is likely the guilty party here. I'm very interested in seeing if React would do a better job of either rendering components efficiently or at least making profiling information more useful, but that probably won't happen until a blur day.