Reduce number of DOM manipulations to improve performance.

[jcass77]

I've tested these optimisations on tracklists of around 2 000 tracks. It basically just replaces the individual DOM manipulations on each item in the tracklist with one large append for the entire table.

Browsing tracks before optimisation:

Browsing tracks after optimisation:

Adding all tracks to Queue using PLAY_ALL before:

After:

[jcass77]

This PR is fairly straightforward and does not change any actual functionality. I think I'll merge it - let me know if it causes anybody any problems.

[kingosticks]

Out of interest, would you expect the 'graphics' time to double after the "browsing tracks" change? I.e is this real and will it affect the initial render time (which is arguably most important) or is this because the performance numbers are generally inaccurate?

[jcass77]

I'm not sure how accurate these are as I just performed a single benchmark as a sanity check. It is possible that the timings for come categories will increase as the browser will now try to render a bigger list at once, instead of incrementally.

I suspect this will differ between browsers and platforms.

In my experience, rendering the table piecemeal did not improve usability. Even though it might start rendering sooner, all of the DOM 'churn' that is happening behind the scenes still meant that the UI would not respond to user interaction. So you could not do much more than wait for everything to finish loading anyway.

It definitely feels faster with the changes applied.

[kingosticks]

Sure, it's not practically useful to render part of the page early but it's visual feedback that something is happening and gives the illusion of being more responsive and is generally preferable on the Web. We shouldn't be battling any data download times so we don't have the usual case here.

[jcass77]

Thinking about it some more: all of the non-function-call-related timings really depend on how long you keep the benchmark running for. So I might just have stopped the benchmark recording for one run before the other.

There would still have been requests to last.fm for all of the album covers etc. So timings that are not directly related to the function calls or DOM manipulation are probably not comparable between runs.