popcorn.js performance: It’s a science
It was a lot of fun to work on, and it brought light down on a couple bugs. One stuck out, being a performance issue. In the demo we had the need to add thousands (5938) of tracks, which all needed to be processed, and it was slow.
Today and yesterday I worked with Rick Waldron to try to figure out a new solution to adding tracks.
Popcorn.js has two arrays of tracks, sorted by time to display and hide the track data. One array is for time to display, the other is time to hide. If you can trust the data is in order by time, hold a reference to the last track that was checked, and have some really good development tests, you can find the data of intrest much much faster, instead of loop through the whole array each iteration 😉
The problem with this though, is data can be added to this array dynamically, at any time, which means data must be sorted each time data is added. As you could imagine, calling any form of a sort function 5938 times, it will begin to get slow. You can hold off on calling sort, but it’s almost impossible to know when to sort again, because of how dynamic things can be. We brainstormed ideas, including a sorted or not sorted flag, which would be checked against once inside the update code. This would mean a new variable is added, and that the update code would have one more task, in what is already time sensitive, optimized code. Not an ideal solution, but a viable idea.
Another idea was sort by default, with the option of the user to override the sort, and call an explicit sort function when they are finished adding data. This is also a viable idea, but the disadvantage is, it is not very user friendly. These things “should just work”.
Third options was, which was the one we ended up going with, to never sort, and make sure tracks are placed in the right location right off the bat. Thingk of it this way, the best way to clean your room, is to never make a mess of it in the first place, and that’s what we did.
What was really cool about all this, was the collaboration and teamwork that pulled this off.
Rick setup a jsperf url, that we could both modify and compare against together. We had a case using the old popcorn event code, and a case with code we could modify, setting a benchmark to beat. Then we both went to work trying ideas, comparing, and mergin ideas into one, until we came up with a jsperf we liked.
What these numbers mean: “we have a 23,891% performance improvement” 😀 which is over 9000.
About half way down the jsperf link, you’ll see a “run tests” button, which will then show you operations per second. Higher is better. Below that, you’ll see the cumulative test of everyone that has run these tests, their numbers, their browser, and how many times it was run. Higher is better, again.