作者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/cn.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