※ 引述《lovebluetea (cchichi)》之铭言： : → Lordaeron:放到RAMDISK中, 这会便宜很多了吧. 绝对比builder便宜 04/26 22:04 : 推 LaPass:java有RAMDISK这个物件吗? 囧" 04/26 22:11 : 推 LaPass:还是Lordaeron把StringBuilder当成硬体之类的.... 04/26 22:13 : → Lordaeron:-_-" 将你的档案丢到ramdisk 不就好了. 需要人教吗? 04/26 23:26 : 推 LaPass:目前我没遇到这麽要求速度的物状况过.... 囧" 04/27 00:13 : → Lordaeron:哪你在问什麽RAMDISK 物件呢? 04/27 09:51 : 推 LaPass:因为在讨论程式码的时候，突然有人跳到硬体方面，感觉焦点 04/27 10:38 : → LaPass:根本没对在一起.... 04/27 10:39 : → LaPass:而且.... 在java中，StringBuilder是非常基础的东西.... 04/27 10:42 : → Lordaeron:StringBuilder 是哪一版的Java 才出现的? 基础? 04/27 10:45 1.4 就有 StringBuffer ， 1.4 到现在少说八九年有了，应该够格说基础了。 对写 java 的人来讲，大量字串处理不用 StringBuffer/StringBuilder ， 我会说他的确是不懂基础没错。 : → 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 ps. 如果改用字串加法 https://gist.github.com/b424fa134cead3593ada 10m左右的文字档，会需要 21秒 （21834 ms ）， 只测 10m 是因为我没耐心等 25m 的资料跑完， 越大就越慢，因为它卡到的是 memory bound 不是 cpu bound。 : 推 LaPass:嗯，焦点果然不同.... 以这个例子而言，问题出在字串相加。 04/27 10:57 : → 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，不要用字串相加那种「鸟算法」。 : 推 LaPass:为什麽跟你客客气气的，你还这麽刺？ = = 04/27 11:17 : → Lordaeron:咦? 客气? 04/27 11:20 -- 网页上拉近距离的帮手 实现 GMail丰富应用的功臣 数也数不清的友善使用者体验 这就是ｊａｖａｓｃｒｉｐｔ 欢迎同好到 AJAX 板一同讨论。 --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 220.135.202.140 ※ 编辑: TonyQ 来自: 220.135.202.140 (04/27 12:53) ※ 编辑: TonyQ 来自: 220.135.202.140 (04/27 12:54)