How we make 5000 row tables fast in Streak
blog.streak.com
blog.streak.com
This technique (particularly calculating the positions of the rows) requires fixed height rows. (There is a solution for variable height rows, but it's a bit more complicated.)
I originally got the idea by looking at google books years ago.
Here is a quick and dirty example as a self-contained HTML file:
https://gist.github.com/3086578
Not to take anything away from any of the mentioned projects, but this pattern is not new or novel.
However, i would not be surprised to find out, that they emulate their own scroll containers. But it is indeed possible and works well.
Ive been following Qooxdoo for quite some time, and the level of browser normalisation ( from keyboard events to how scrollbars render ) is insane.
And so is the performance, and the tricks they pull. For example: they recyle dom nodes. They have different array looping constructs based on the target platform. They emulate their own event bubbling system. There is a whole range of performance tests you can try on their website as well.
The real question is, can we get this kind of performance with more idiomatic html/css.
However, on iOS, I can't seem to disable the bounce scrolling of the entire screen if I have any scrollable areas on the screen. So I ended up writing a decorator for overflow:auto elements that re-implements touch scrolling. And does a preventDefault() as necessary to prevent the bounce of the app.
Here is a gist of the decorator:
https://gist.github.com/3086981
It works on the iPad, but I can't vouch for android. (This code is from a little weekend project.)
Edit: I didn't implement rubber banding or anything. It's just a quick and dirty scroll with some inertia based on a weighted average velocity of the last two touchmove events. It doesn't feel too bad, but it isn't perfect.
It can cause some quirky behavior so test it out carefully but you get much better performance with long lists if using it.
Eg with properties a,b it sorts on a, then sorts the list again based on b. The list is now in b-order (not a-order) and b-equal blocks are only in a-order if the sort is stable. Meanwhile, the 'fast' algortithm is in a-order with b-ordered a-equal blocks.
More on that here: http://layervault.tumblr.com/post/26117253199/making-a-new-t...
1. position:relative; or absolute on the ccell or within a cell causes same slowdown as overflow:hidden.
2. On iOS, overflow:hidden and position:relative on cells can cause serious slowdowns later when an absolute div later dynamically over document.
3. Beware of tables in IE8 - changing className of div in cell or other changes can cause complete table reflow calc - found out using commercial profiler that gives information about reflow/redraw times.
I'm interested to know more about how and why you are using this "Levinshtein distance" (Fast Levinshtein) algorithm. I looked at the Wikipedia and the explanation makes sense; it's just not sinking in as to where I might think about making use of it in my own code.
edit: here's the video http://www.youtube.com/watch?v=o1O7HkBj74c
Please.
Edit: the article says 5000 rows, 10 columns. Hm.
And on my desktop Javascript uses most of the browser's memory. No thanks.