Re: [問題] 更有效率的讀檔?

看板java作者 (Terry)時間12年前 (2012/04/27 14:33), 編輯推噓0(0015)
留言15則, 6人參與, 最新討論串4/8 (看更多)
※ 引述《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

04/27 14:35, , 1F
我只提一件事 StringBuffer 官方說明是由 JDK1.0 起有的
04/27 14:35, 1F

04/27 14:36, , 2F
證據: http://tinyurl.com/cs57wnr Since: JDK 1.0
04/27 14:36, 2F

04/27 14:37, , 3F
JDK 1.0 是什麼時代? 1996 年啊同學
04/27 14:37, 3F

04/27 14:43, , 4F
咦, 對呢, 哪怎麼會哪個年代沒人在提呢?
04/27 14:43, 4F

04/27 15:56, , 5F
有沒有人要試試String+搭配Ramdisk的實際速度?(好奇)
04/27 15:56, 5F

04/27 16:29, , 6F
可以噓嗎?
04/27 16:29, 6F

04/27 17:41, , 7F
請便.
04/27 17:41, 7F

04/27 20:30, , 8F
根本就只是來鬧的,人家在討論code你說code不重要...
04/27 20:30, 8F

04/27 20:31, , 9F
能用錢去方便解決的, code 就不重要了. 這是現實.
04/27 20:31, 9F

04/27 20:35, , 10F
你真的很活在自己的世界,沒有人否定改善硬體這方法,
04/27 20:35, 10F

04/27 20:37, , 11F
但人家是在討論如何從code上改善,你卻在一直否定這個
04/27 20:37, 11F

04/27 20:41, , 12F
思考方向,你提好的建議當然是好事,不必用否定來凸顯
04/27 20:41, 12F

04/27 22:38, , 13F
整串下來, 誰鬧誰了? 誰提RAMDISK物件的?
04/27 22:38, 13F

04/27 23:30, , 14F
我覺得Ramdisk這個建議不算很誇張,但很想看實測數據
04/27 23:30, 14F

04/28 12:54, , 15F
反過來說只要從code下手 就可以省下硬體的錢了
04/28 12:54, 15F
文章代碼(AID): #1FcZsdvv (java)
討論串 (同標題文章)
文章代碼(AID): #1FcZsdvv (java)