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

看板java作者 (cchichi)時間13年前 (2012/04/25 23:47), 編輯推噓16(16推 0噓 26→)
留言42則, 12人參與, 最新討論串1/8 (看更多)
各位大大好… 小弟在解usaco的時候遇到了一個問題。 他給了我一個測試檔 大概有3000行左右 我用bufferReader去讀取 程式大概是這樣 BufferedReader f = new BufferedReader(new FileReader("prefix.in")); S = f.readLine(); while (f.ready()) S += f.readLine(); 這樣的結果是正確的，遇到的問題是 這個程式要在1sec內解出來 小弟的電腦測試這個程序居然就要1.8sec... 主要架構的部份沒有問題，想請問版上大大 這個問題有辦法改良嗎? 有找過一些，但是沒有什麼頭緒^^" 謝謝 以這個程式來說，我塞test data的資料結果是正確的，時間大約2sec 讀取部份為1.8 sec..所以我才想從這邊改進 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 111.251.199.98 ※ 編輯: lovebluetea 來自: 111.251.199.98 (04/25 23:52)
→
04/25 23:51, , 1F
S 是 String 的話改用 StringBuilder/StringBuffer 試試?
04/25 23:51, 1F
推
04/25 23:53, , 2F
1f正解 那速度差非常多
04/25 23:53, 2F
→
04/25 23:58, , 3F
感謝 S是string 沒錯 我試試看
04/25 23:58, 3F
→
04/26 00:17, , 4F
謝謝...測試已過 速度為0.4S QQ"
04/26 00:17, 4F
→
04/26 00:22, , 5F
buffer為0.5sec 似乎較慢!?
04/26 00:22, 5F
推
04/26 00:35, , 6F
那0.1秒差不多都少，比較重要的差別在於執行緒安全
04/26 00:35, 6F
推
04/26 00:37, , 7F
了多
04/26 00:37, 7F
推
04/26 09:39, , 8F
要看看是不是瓶頸和呼喚次數才知道0.1秒的影響大不大..
04/26 09:39, 8F
→
04/26 10:29, , 9F
既然要串成字串,不如先用File得知檔案長度,new 一個byte[]
04/26 10:29, 9F
→
04/26 10:32, , 10F
一次讀取,再轉成String會不會好一點?PS:推文間隔有夠長Orz
04/26 10:32, 10F
→
04/26 13:38, , 11F
換個快一點的HD不就好了.
04/26 13:38, 11F
→
04/26 18:16, , 12F
樓上，這個代價比用StringBuilder高很多啊~
04/26 18:16, 12F
→
04/26 22:04, , 13F
放到RAMDISK中, 這會便宜很多了吧. 絕對比builder便宜
04/26 22:04, 13F
推
04/26 22:11, , 14F
java有RAMDISK這個物件嗎? 囧"
04/26 22:11, 14F
推
04/26 22:13, , 15F
還是Lordaeron把StringBuilder當成硬體之類的....
04/26 22:13, 15F
→
04/26 23:26, , 16F
-_-" 將你的檔案丟到ramdisk 不就好了. 需要人教嗎?
04/26 23:26, 16F
推
04/27 00:13, , 17F
目前我沒遇到這麼要求速度的物狀況過.... 囧"
04/27 00:13, 17F
→
04/27 09:51, , 18F
哪你在問什麼RAMDISK 物件呢?
04/27 09:51, 18F
推
04/27 10:38, , 19F
因為在討論程式碼的時候，突然有人跳到硬體方面，感覺焦點
04/27 10:38, 19F
→
04/27 10:39, , 20F
根本沒對在一起....
04/27 10:39, 20F
→
04/27 10:42, , 21F
而且.... 在java中，StringBuilder是非常基礎的東西....
04/27 10:42, 21F
→
04/27 10:45, , 22F
StringBuilder 是哪一版的Java 才出現的? 基礎?
04/27 10:45, 22F
→
04/27 10:46, , 23F
搞不懂為什麼會跳過這個解法，去換HD或是使用RAMDISK....
04/27 10:46, 23F
→
04/27 10:47, , 24F
因為你檔案一大,什麼都沒用Java就是慢.
04/27 10:47, 24F
→
04/27 10:48, , 25F
開個600K 還要16s, 6MB呢?60MB?
04/27 10:48, 25F
推
04/27 10:57, , 26F
嗯，焦點果然不同.... 以這個例子而言，問題出在字串相加。
04/27 10:57, 26F
→
04/27 10:59, , 27F
很感謝你提供RAMDISK的方法，有用到大檔案時，我會記得的
04/27 10:59, 27F
→
04/27 10:59, , 28F
你不用去解釋什麼不同, 不然你就拼一下不作字串相加好
04/27 10:59, 28F
→
04/27 11:01, , 29F
了,看會快多少? 檔案處理本來就不適合Java/perl之類做
04/27 11:01, 29F
→
04/27 11:04, , 30F
大檔更是慘. 非得要的話, 請別去想改什麼鳥算法的.
04/27 11:04, 30F
推
04/27 11:17, , 31F
為什麼跟你客客氣氣的，你還這麼刺？ = =
04/27 11:17, 31F
→
04/27 11:20, , 32F
咦? 客氣?
04/27 11:20, 32F
推
04/27 13:50, , 33F
為什麼有人要堅持 O(n^2) 配好硬碟會比 O(n) 快呢？
04/27 13:50, 33F
推
04/27 13:55, , 34F
60MB 配 S += f.readLine() 應該會 garbage collection 到死
04/27 13:55, 34F
→
04/27 14:34, , 35F
new 一個60MB 的byte array, 一口氣讀上來, 再轉字串.
04/27 14:34, 35F
推
04/27 19:37, , 36F
不要笑死人了 StringBuilder是基礎中的基礎沒錯
04/27 19:37, 36F
推
04/27 21:04, , 37F
真是又好氣又好笑= = 這是java版還是硬體版阿..
04/27 21:04, 37F
→
04/27 22:36, , 38F
咦, 是呢1.5 才有的基礎.
04/27 22:36, 38F
→
04/28 00:28, , 39F
我倒覺得基不基礎不重要，重點是真的快很多
04/28 00:28, 39F
推
04/28 04:59, , 40F
先說「別去想改什麼鳥算法」再改口 new 60MB byte array 哈
04/28 04:59, 40F
→
05/08 20:33, , 41F
如果換行對程式沒意義,又純英文.readline可以換掉
05/08 20:33, 41F
推
05/11 15:45, , 42F
StringBuilder真的很基本沒錯阿＝＝
05/11 15:45, 42F
‣ 更多 lovebluetea 的文章
文章代碼(AID): #1Fc1oO9j (java)
討論串 (同標題文章)
以下文章回應了本文 (最舊先)：
完整討論串 (本文為第 1 之 8 篇)：
排序： 最新先 | 最舊先 | 留言數
在新視窗開啟完整討論串 (共8篇)
‣ 更多 lovebluetea 的文章
文章代碼(AID): #1Fc1oO9j (java)