Just looking through the source to try and ID how something is added to the RE, I noticed this code in
I've noticed that one of the slowest parts of the RE, when it parses, is that each row is created and displayed one by one. There's 4 big ways that this code could be sped up, without much effort/code change at all.
First, it's adding the rows one by one. DOM entity insertions are essentially linear - O. Insertion into the DOM is slow, whereas rendering that insertion is super fast, regardless of the size of the insertion. So inserting rows into the DOM one by one is far slower than inserting them into a fragment, then only inserting the fragment into the DOM once you're done.
Second, it's repeating the cloned track row search for each new row. Again, this is O, where it only needs to be done once. (It's also repeating the self.$table.find ('tbody') search, but that's already eliminated with the first improvement.)
Third, it's using the .eq() function instead of the :eq() selector (or better yet, the :first selector); the former involves an unneeded function call, plus it collects every match, then eliminates all but the matching one (O(n^2) at best). :eq() only collects the matching ones, which is better (O) - and in this case, since you only want :eq(0), best is to just use :first, so it stops after collecting the first match (O(1)).
Fourth, after adding the tr to the DOM, it's then doing four class traversals of the entire tr, each time manipulating the text contents of a td within that tr - class traversal is slow, plus each text manipulation is a DOM replacement (jQuery is internally rewriting the td). Far faster to do just one traversal (there will only ever be one each of position, title, artist, and length, and always in that order), and to do the replacements within a tr in a fragment (#1 above) rather than within the DOM itself.