→ mmis1000: 就先用 Array.sort 把date相同的排在一起 07/15 23:39
→ mmis1000: 然後用for loop把連續重複一樣的刪除阿 07/15 23:40
→ mmis1000: 這壓根兒跟D3.js沒半點關係啊？ 07/15 23:40
→ mmis1000: 要切資料自己直接來比較快阿 07/15 23:42
→ carylorrk: 資料量大可以用 hash 取代 sort 07/16 17:27
→ mmis1000: sort理論上是最快的，時間系數是 nlog2n 07/16 17:45
→ mmis1000: 不做sort暴力爬則是 n^2 ，跟bubble sort一樣 07/16 17:47
→ mmis1000: 資料量一大保證當機 07/16 17:47
→ allen511081: 感謝兩位的指教，兩種方法我都來試看看 07/16 17:48
→ carylorrk: 如果不需排序後的資料，hash aggregate 在資料量大時 07/17 09:03
→ carylorrk: 通常比較快吧？ 07/17 09:03
→ carylorrk: 理論上 average time complexity 是 O(n)，但是 space 07/17 09:20
→ carylorrk: requirement 較高...不過我沒在 JS 做過就是（看右上角 07/17 09:20
推 carylorrk: 不過如果時間不是 sparse，integer sort 更方便 07/17 09:36
→ mmis1000: js用object來lookup property不會比sort快阿 07/17 17:50
→ mmis1000: js的property lookup很慢 07/17 17:51
推 eight0: 不是 property lookup 的問題吧。就是在大量增刪物件屬性 07/18 01:28
→ eight0: 時效率很差。資料不大時 hash table 應該還是贏的 07/18 01:28
→ eight0: 可能和記憶體控管有關？ 07/18 01:29
→ mmis1000: 應該說，他的物件是可以放任何屬性資料，不像一般的MAP 07/18 10:07
→ mmis1000: 可以對單一型態的物件做最佳化 07/18 10:07
→ mmis1000: 聽說V8為了對應讀取慢的問題，把object compile成hidden 07/18 10:10
→ mmis1000: class object了 07/18 10:10
→ mmis1000: 時間並不是線性增加的，有得時候obj快，有得時候arr快 07/18 11:15
→ mmis1000: 不過sort在重複物件很多的場合或是大量物品時是比較慢的 07/18 11:16
→ mmis1000: 更正，是sort在物品多+重複少時會比較快 07/18 11:17
→ mmis1000: 然後firefox的sort慢到爆炸，chrome的反而很快 07/18 12:17
推 eight0: Sort 在重複多時不可能比較慢，極端狀況就是所有項目都相 07/19 03:34
→ eight0: 同，此時 sort 相當於 O(n) 07/19 03:34
推 mmis1000: firefox的sort慢是因為他會經過兩層JIT,而chrome的sort 07/19 10:59
→ mmis1000: 本身就是js 07/19 10:59
→ mmis1000: 而且預設的sort是merge sort，時間一定是nlogn 07/19 11:01
→ mmis1000: 如果做出timesort應該會快很多 07/19 11:01
→ mmis1000: 在bugzilla有討論這個問題的issue 07/19 11:02
→ mmis1000: 是說就算是mergesort 100萬筆也不超過3秒拉 07/19 11:11
→ eight0: count 是比較次數。在 Firefox 上是線性成長，V8 有點微妙 07/20 18:44
→ mmis1000: 應該是做了啥optimize吧？不看source不知道 07/20 19:17