Simplest and best column sorting in HTML table?
in [JavaScript]
|
Prev: SlickSpeed: jquery vs mylib
Next: FAQ Topic - How do I format a Date object with javascript? (2010-01-27)
From: Evertjan. on 28 Jan 2010 13:28 Gregor Kofler wrote on 28 jan 2010 in comp.lang.javascript: > Evertjan. meinte: >> dorayme wrote on 27 jan 2010 in comp.lang.javascript: >>> <http://dorayme.netweaver.com.au/tableSort/tableSortCandidate.html >> >> While I hate "simplest and best" Q, >> column sorting can be done much simpler, >> with only a few lines of javascript script: >> >> [Chrome and IE8 tested] >> >> ========================================= > [snip] > > Indeed - and it might be sufficient for dorayme's case. But your > solution won't work with (non-iso) dates, (formatted) numbers, etc. That can be said for any solution, that certain requiremwents are not met and need to be added IF required, but the OQ was "Simplest and best column sorting in HTML table", so I don't see why all those components need to be added in a heavy library scriptfile. > Besides, since you swap the contents of the cells and not the cell > elements itself you will lose attached event listeners. "Simplest and best column sorting in HTML table"? > And I suppose > since every innerHTML assignment for every cell triggers a reflow this > could be rather slow. In my example it is flashingly fast, and you do not have to upload a large js file. Remember? "Simplest and best column sorting in HTML table" -- Evertjan. The Netherlands. (Please change the x'es to dots in my emailaddress)
From: Gregor Kofler on 28 Jan 2010 15:18 Evertjan. meinte: > Gregor Kofler wrote on 28 jan 2010 in comp.lang.javascript: >> Indeed - and it might be sufficient for dorayme's case. But your >> solution won't work with (non-iso) dates, (formatted) numbers, etc. > > That can be said for any solution, that certain requiremwents are not met > and need to be added IF required, > but the OQ was "Simplest and best column sorting in HTML table", Simple - yes. Primitive? Maybe not. Sorting is only supported in one direction; and *only* sorting for strings is most of the time useless (dorayme's postcodes could become a problem). > so I don't see why all those components need to be added in a heavy library > scriptfile. Er... my script is a mere 4k including a few comments. If you copy the needed functions from the core library you'd end up with maybe 6k or 7k. It's definitely longer than yours but "heavy"? This is the (ugly) era of GP libraries like YUI and Ext JS... >> Besides, since you swap the contents of the cells and not the cell >> elements itself you will lose attached event listeners. > > "Simplest and best column sorting in HTML table"? > >> And I suppose >> since every innerHTML assignment for every cell triggers a reflow this >> could be rather slow. > > In my example it is flashingly fast, and you do not have to upload a large > js file. Flashingly fast? Are you sure? I've tried your solution on a larger table (200 rows, columns Name1 and City): http://vxjs.gregorkofler.com/?page=sortable FF 3.5(a)Ubuntu 9.10 gives me on average 1,150ms with your solution and 290ms with mine (even with the overhead of "fancy" sorting). Chromium 5.0(a)Ubuntu 9.10 *is* blazingly fast: 90ms for your solution - 25ms for mine. Opera 10 45ms vs. 190ms. Speed won't be an issue in the latter case, but with FF I it's either "slow" or "unbearably sluggish". With 5 rows you won't notice a difference. But then: Why should one want to sort 5 rows? Gregor -- http://www.gregorkofler.com
From: dorayme on 28 Jan 2010 16:32 In article <Xns9D0E755C21C52eejj99(a)194.109.133.242>, "Evertjan." <exjxw.hannivoort(a)interxnl.net> wrote: > dorayme wrote on 27 jan 2010 in comp.lang.javascript: > > <http://dorayme.netweaver.com.au/tableSort/tableSortCandidate.html > > While I hate "simplest and best" Q, > column sorting can be done much simpler, > with only a few lines of javascript script: > > [Chrome and IE8 tested] > > ========================================= > <script type='text/javascript'> > > function sorter(x,sortCol) { > > var i,j,y,r = [] Good effort Evertjan, for a secret yogurt recipe of mine, or one of the best jokes in the world, interested in extending it to a combined stable script that *stripes* the rows and sorts just the towns or postcodes, *nothing else*, better and simpler than: http://dorayme.netweaver.com.au/tableSort/tableSortCandidate.html ? -- dorayme
From: Michael Wojcik on 30 Jan 2010 11:50 Gregor Kofler wrote: > > Interesting. I had then replaced the built-in sort with my "own" > quicksort function and it was only slighlty slower. Since the sorting > itself wasn't an issue when compared to the "speed" of the required DOM > operations, I didn't investigate any further and stuck to the built-in > algorithm (according to the various Wikipedia articles quicksort, > mergesort and minsort don't differ too much in terms of speed). For the amount of data you're likely to be sorting in an ECMAScript program, implementation will probably matter far more than algorithm. Quicksort and Mergesort are both generally described as O(n lg n) algorithms[1], while the "min sort" (basically just a Selection Sort) is, as Lasse said, O(n**2). This is all with complexity measured as average number of comparisons in non-pathological cases. But the average number of comparisons is obviously only part of the story. A naive Quicksort, for example, degrades to O(n**2) if the input is already sorted. There are strategies to avoid this (eg median-of-three in pivot selection, or Introsort's detect-and-dodge approach), but they mean additional code complexity. And Quicksort is defined recursively, but for optimal performance on datasets of significant size it's usually much better to implement it iteratively - again, complicating the code, and leading to more work in the inner loop, possible cache misses, etc. Mergesort is straightforward, but it tends to have lousy locality of reference once the large merges start. It's handy for sorts that have to spill to disk (or slower media), but often not ideal for in-memory sorting. And again, the obvious recursive implementation, though elegant in source, will likely lose to an iterative one. Then there are all the usual optimization concerns: memory consumption, hoisting code out of the inner loop, and so forth. (Looking at the implementation of "min sort" in WebKit that Lasse linked to, I can't help but wonder if it wouldn't be better to do more preprocessing and get rid of some of those tests in the inner loop. Yikes.) And for sorts that are actually implemented in ES, a lot will depend on how the underlying interpreter works. Interpreting tokenized code at runtime, for example, is relatively expensive because it ends up doing indirection through some sort of lookup table. That makes the path length of the sort's inner loop important for ES engines that are true interpreters. On the other hand, an ES engine that does JIT compilation would not be sensitive to this effect, and if the inner-loop code fit in a CPU cache slot, additional complexity could very well pay off. [1] We can leave out the well-known complaints about casual abuse of complexity notation, etc. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State University
From: Evertjan. on 30 Jan 2010 18:04
Gregor Kofler wrote on 28 jan 2010 in comp.lang.javascript: > Evertjan. meinte: >> Gregor Kofler wrote on 28 jan 2010 in comp.lang.javascript: > >>> Indeed - and it might be sufficient for dorayme's case. But your >>> solution won't work with (non-iso) dates, (formatted) numbers, etc. >> >> That can be said for any solution, that certain requiremwents are not >> met and need to be added IF required, >> but the OQ was "Simplest and best column sorting in HTML table", > > Simple - yes. Primitive? Maybe not. Sorting is only supported in one > direction; and *only* sorting for strings is most of the time useless > (dorayme's postcodes could become a problem). What nonsense, as I said my example is extreamely exteneble. >> so I don't see why all those components need to be added in a heavy >> library scriptfile. > > Er... my script is a mere 4k including a few comments. If you copy the > needed functions from the core library you'd end up with maybe 6k or > 7k. It's definitely longer than yours but "heavy"? This is the (ugly) > era of GP libraries like YUI and Ext JS... "core library", terrible idea! >>> Besides, since you swap the contents of the cells and not the cell >>> elements itself you will lose attached event listeners. >> >> "Simplest and best column sorting in HTML table"? >> >>> And I suppose >>> since every innerHTML assignment for every cell triggers a reflow >>> this could be rather slow. >> >> In my example it is flashingly fast, and you do not have to upload a >> large js file. > > Flashingly fast? Are you sure? > > I've tried your solution on a larger table (200 rows, columns Name1 > and City): > http://vxjs.gregorkofler.com/?page=sortable Tables of "200 rows"? Those things should not be on a HTML page. Lasrge datacollections should be searched by search strings and prepared by serverside code and not scrolled foer visual search clientsidde. > FF 3.5(a)Ubuntu 9.10 gives me on average 1,150ms with your solution and > 290ms with mine (even with the overhead of "fancy" sorting). > > Chromium 5.0(a)Ubuntu 9.10 *is* blazingly fast: 90ms for your solution - > 25ms for mine. > > Opera 10 45ms vs. 190ms. So what differense would that make on a talbe of max 20 rows, more is not accepable anyway. > Speed won't be an issue in the latter case, but with FF I it's either > "slow" or "unbearably sluggish". With 5 rows you won't notice a > difference. But then: Why should one want to sort 5 rows? You are just trying to confuse the issue. See above and ask the OP what he wants. -- Evertjan. The Netherlands. (Please change the x'es to dots in my emailaddress) |