作者allen511081 (藍)
看板Ajax
標題[問題]用D3.js載入的時間資料如何做判斷?
時間Wed Jul 15 21:34:13 2015
自己也是剛接觸JS沒多久，對於JS語法還不熟悉，不知道版上有沒有會D3的人，
我自己寫了兩個網頁，一個u21.html，一個u23.html，u23用jquery將選擇的選項
傳到u21裡，而u21裡的D3根據選項將對應的CSV檔載入後，依照key值將資料做堆疊，
再來就是我不會做判斷的地方，我該如何判斷資料裡的日期是否一樣 ? 若一樣，
就將資料裡的數量加起來後，留下一筆資料，例:
date birdName count
1999/10/01 XXX 2
1999/10/08 XXX 3
1999/10/01 XXX 4
變成
date birdName count
1999/10/01 XXX 6
1999/10/08 XXX 3
請版上的強者指導一下
附上
u21:
https://goo.gl/Wuhk6q
u23:
https://goo.gl/2R6uFx
相對應CSV:1.
https://goo.gl/sKMvu5
2.
https://goo.gl/AlIw8k
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 220.132.247.33
※ 文章網址: https://webptt.com/m.aspx?n=bbs/Ajax/M.1436967256.A.FD0.html
1F：→ mmis1000: 就先用 Array.sort 把date相同的排在一起 07/15 23:39
2F：→ mmis1000: 然後用for loop把連續重複一樣的刪除阿 07/15 23:40
3F：→ mmis1000: 這壓根兒跟D3.js沒半點關係啊？ 07/15 23:40
4F：→ mmis1000: 要切資料自己直接來比較快阿 07/15 23:42
5F：→ carylorrk: 資料量大可以用 hash 取代 sort 07/16 17:27
6F：→ mmis1000: sort理論上是最快的，時間系數是 nlog2n 07/16 17:45
7F：→ mmis1000: 不做sort暴力爬則是 n^2 ，跟bubble sort一樣 07/16 17:47
8F：→ mmis1000: 資料量一大保證當機 07/16 17:47
9F：→ allen511081: 感謝兩位的指教，兩種方法我都來試看看 07/16 17:48
10F：→ carylorrk: 如果不需排序後的資料，hash aggregate 在資料量大時 07/17 09:03
11F：→ carylorrk: 通常比較快吧？ 07/17 09:03
12F：→ carylorrk: 理論上 average time complexity 是 O(n)，但是 space 07/17 09:20
13F：→ carylorrk: requirement 較高...不過我沒在 JS 做過就是（看右上角 07/17 09:20
14F：推 carylorrk: 不過如果時間不是 sparse，integer sort 更方便 07/17 09:36
15F：→ mmis1000: js用object來lookup property不會比sort快阿 07/17 17:50
16F：→ mmis1000: js的property lookup很慢 07/17 17:51
17F：推 eight0: 不是 property lookup 的問題吧。就是在大量增刪物件屬性 07/18 01:28
18F：→ eight0: 時效率很差。資料不大時 hash table 應該還是贏的 07/18 01:28
19F：→ eight0: 可能和記憶體控管有關？ 07/18 01:29
20F：→ mmis1000: 應該說，他的物件是可以放任何屬性資料，不像一般的MAP 07/18 10:07
21F：→ mmis1000: 可以對單一型態的物件做最佳化 07/18 10:07
22F：→ mmis1000: 聽說V8為了對應讀取慢的問題，把object compile成hidden 07/18 10:10
23F：→ mmis1000: class object了 07/18 10:10
25F：→ mmis1000: 時間並不是線性增加的，有得時候obj快，有得時候arr快 07/18 11:15
26F：→ mmis1000: 不過sort在重複物件很多的場合或是大量物品時是比較慢的 07/18 11:16
27F：→ mmis1000: 更正，是sort在物品多+重複少時會比較快 07/18 11:17
28F：→ mmis1000: 然後firefox的sort慢到爆炸，chrome的反而很快 07/18 12:17
29F：推 eight0: Sort 在重複多時不可能比較慢，極端狀況就是所有項目都相 07/19 03:34
30F：→ eight0: 同，此時 sort 相當於 O(n) 07/19 03:34
31F：推 mmis1000: firefox的sort慢是因為他會經過兩層JIT,而chrome的sort 07/19 10:59
32F：→ mmis1000: 本身就是js 07/19 10:59
33F：→ mmis1000: 而且預設的sort是merge sort，時間一定是nlogn 07/19 11:01
34F：→ mmis1000: 如果做出timesort應該會快很多 07/19 11:01
35F：→ mmis1000: 在bugzilla有討論這個問題的issue 07/19 11:02
36F：→ mmis1000: 是說就算是mergesort 100萬筆也不超過3秒拉 07/19 11:11
38F：→ eight0: count 是比較次數。在 Firefox 上是線性成長，V8 有點微妙 07/20 18:44
39F：→ mmis1000: 應該是做了啥optimize吧？不看source不知道 07/20 19:17