2011-12-26 88 views
1

複印時,公地IO使用本地緩存:應該使用全局緩衝區而不是本地緩衝區?

http://svn.apache.org/viewvc/commons/proper/io/trunk/src/main/java/org/apache/commons/io/CopyUtils.java?view=markup (搜索DEFAULT_BUFFER_SIZE)

而Eclipse使用靜態同步緩衝,防止併發複製操作: http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.core.resources/src/org/eclipse/core/internal/utils/FileUtil.java?view=markup (搜索緩存)

看起來靜態緩衝區可能會在順序處理小文件時提高性能,但會降低並行副本的性能。

eclipse靜態同步緩衝區是否具有現實世界的性能改進,或者它只是過度工程?

你在這種情況下推薦使用什麼?

回答

2

它確實沒有顯着的性能差異,除非你知道你是線程安全的,否則靜態緩衝區通常是一個非常糟糕的主意。他們這樣做(如果你看看評論),因爲他們理解更高級別對象中的同步。

所以總是分配一個動態緩衝區。

+1

的Apache Commons是超過10歲,當虛擬機分配的時候已經不太有效寫內存和多核CPU的時間比今天少得多。 – x4u 2011-12-26 19:13:23

+0

@ x4u Apache Commons未使用靜態緩衝區。你的意思是說靜態緩衝區是首選嗎?你能解釋爲什麼嗎? – Eduardo 2011-12-27 17:58:39

+0

對不起,我錯了。我認爲Commons正在使用靜態緩衝區。我會建議不要使用靜態緩衝區。 – x4u 2011-12-27 21:37:27

0

我更喜歡commons-io方法:更容易閱讀,性能可能非常相似。

成本是,commons-io將創建一個新的字節[8192]每次copy()調用一次。但請記住兩件事:

  1. 新字節[8192]在大多數系統上幾乎是瞬時的。這不是一個昂貴的構造函數來調用!

  2. InputStream.read()在大多數情況下通常非常緩慢! (例如文件的閱讀,或者套接字讀取!)

所以新的字節[8192]電話會非常快相比實際的流複製。 Eclipse優化(在這個特定的例子中)是一個虛假的經濟(它不是瓶頸!),導致更復雜,更難理解的代碼。

0

如果您擔心性能,我會使用直接的ByteBuffers。這種緩衝在出現時是最好的,但NIO(自2004年以來可用)是更快的恕我直言。 (高達30%)

否則,分配的成本是非常小的(除非你正試圖避免GCS)