作者Lordaeron (Terry)
看板java
标题Re: [问题] 更有效率的读档?
时间Fri Apr 27 14:33:08 2012
※ 引述《TonyQ (自立而後立人。)》之铭言：
: : → Lordaeron:StringBuilder 是哪一版的Java 才出现的? 基础? 04/27 10:45
: 1.4 就有 StringBuffer ， 1.4 到现在少说八九年有了，应该够格说基础了。
: 对写 java 的人来讲，大量字串处理不用 StringBuffer/StringBuilder ，
: 我会说他的确是不懂基础没错。
哪麽1.0 的要叫什麽?
不然改用java 最红时代的1.2 好了?
: : → LaPass:搞不懂为什麽会跳过这个解法，去换HD或是使用RAMDISK.... 04/27 10:46
: : → Lordaeron:因为你档案一大,什麽都没用Java就是慢. 04/27 10:47
: : → Lordaeron:开个600K 还要16s, 6MB呢?60MB? 04/27 10:48
: 有几分证据说几分话。
: 这里有一个 zip 档，解开有一个 25m 的纯文字档，里面有 26280800 个字元。
: http://tonyq.org/test/test.zip
: 测试程式码在测，全部读完的时间我本机测是 432ms 。
: https://gist.github.com/b02a3e300c2a94e445ba
: 600K 要 16s ，不知道是再怎样的极端条件或环境下才会产生的数据。
: 我从学生时代就很常用 java 作 web crawler ，
: 动辄几十 m 百 m 的资料处理，从没碰过你说这麽慢的状况。
: Java 很显然不会是最快的 solution ，但也没这麽不堪啊。XD
因为你只有百M, 你可以改一下, 300MB, 700MB 看看.
: ps. 如果改用字串加法
: https://gist.github.com/b424fa134cead3593ada
: 10m左右的文字档，会需要 21秒 （21834 ms ），
: 只测 10m 是因为我没耐心等 25m 的资料跑完，
啊, 21秒就没耐心了, 不是没哪麽慢吗?
: 越大就越慢，因为它卡到的是 memory bound 不是 cpu bound。
这东西本来就是IO Bound 需要讲的吗?
: : → LaPass:很感谢你提供RAMDISK的方法，有用到大档案时，我会记得的 04/27 10:59
: : → Lordaeron:你不用去解释什麽不同, 不然你就拼一下不作字串相加好 04/27 10:59
: : → Lordaeron:了,看会快多少? 档案处理本来就不适合Java/perl之类做 04/27 11:01
: : → Lordaeron:大档更是惨. 非得要的话, 请别去想改什麽鸟算法的. 04/27 11:04
: 量大的话大概会快个十百倍吧，就以刚刚那个例子来看，
: 就有超过百倍，这取决於你记忆体有多大。
: 以 String concat 来讲，有大量字串操作，
: 请记得要改一下用 StringBuffer，不要用字串相加那种「鸟算法」。
为何1.0, 1.1, 1.2 都不需要StringBuffer, 或StringBuilder 呢?
就是因为一些programmer 懒了, 不会去想别的方式, 习惯性使用String
来存放资料. 而不会转一下方法之过.
--
※ 发信站: 批踢踢实业坊(ptt.cc)
◆ From: 210.59.250.101
1F：→ LPH66:我只提一件事 StringBuffer 官方说明是由 JDK1.0 起有的 04/27 14:35
3F：→ LPH66:JDK 1.0 是什麽时代? 1996 年啊同学 04/27 14:37
4F：→ Lordaeron:咦, 对呢, 哪怎麽会哪个年代没人在提呢? 04/27 14:43
5F：→ james732:有没有人要试试String+搭配Ramdisk的实际速度？(好奇) 04/27 15:56
6F：→ sqrt998001:可以嘘吗？ 04/27 16:29
7F：→ Lordaeron:请便. 04/27 17:41
8F：→ risker760915:根本就只是来闹的,人家在讨论code你说code不重要... 04/27 20:30
9F：→ Lordaeron:能用钱去方便解决的, code 就不重要了. 这是现实. 04/27 20:31
10F：→ risker760915:你真的很活在自己的世界,没有人否定改善硬体这方法, 04/27 20:35
11F：→ risker760915:但人家是在讨论如何从code上改善,你却在一直否定这个 04/27 20:37
12F：→ risker760915:思考方向,你提好的建议当然是好事,不必用否定来凸显 04/27 20:41
13F：→ Lordaeron:整串下来, 谁闹谁了? 谁提RAMDISK物件的? 04/27 22:38
14F：→ james732:我觉得Ramdisk这个建议不算很夸张，但很想看实测数据 04/27 23:30
15F：→ cha122977:反过来说只要从code下手 就可以省下硬体的钱了 04/28 12:54