軟體效能的設計（三）資料型別對軟體效能的影響 (轉)

軟體效能的設計（三）資料型別對軟體效能的影響 (轉)[@more@]

  的設計（三）資料型別對軟體效能的影響
  劉彥清·yesky

　　BadRegExpMatcher要求Bot將輸入文字由字元陣列轉換為一個String，從而導致了不必要的物件建立。然而，滑稽的是為了更方便地使用輸入文字，BadRegExpMatcher會立即將String物件轉換為一個字元陣列，這樣不但會生成另一個物件，還意味著你在費了九牛二虎之力得到的結果，跟最初提供的資料沒有什麼二樣，MailBot和BadRegExpMatcher都不要求使用String物件，String物件似乎僅僅是為也在之間文字資料而存在的。

　　在上面的BadRegExpMatcher例子中，String僅僅是一種供交換用的型別，無論是呼叫程式還是被呼叫程式都不需要使用供交換用的資料型別來表示資料，但它們可以很方便地把它與其他的資料型別進行轉換。儘管在定義介面時採用供交換用的資料型別可以在保持靈活性的前提下降低複雜性，但有時會帶來效能上的損失。

　　供交換用資料型別的一個最常見的例子是JC ResultSet介面，沒有一種的介面會用 ResultSet表示返回的結果，但JDBC程式可以很方便地把資料庫返回的結果轉換為JDBC ResultSet型資料。同樣，也沒有一種客戶端軟體用DBC ResultSet型資料表示資料記錄，但你也可以不費什麼勁兒就將ResultSet型資料轉換為所需要的資料型別。在JDBC中我們可以接受這種"多此一舉"，因為它具有標準性和跨資料庫的可移植性等好處。無論如何，由供交換用資料型別所帶來的效能損失都是一個值得注意的問題。

　　在RegExpMatcher中，在定義介面時使用String物件對減少複雜性或增加可移植性的幫助並不大，對效能卻有著相當大的影響，這麼做是得不償失的。在設計介面時使用可互換型別往往很有吸引力，因為這樣能夠使介面看起來更"乾淨"一些，但你應該確信你為此所作的折衷是明智的。有時━━就象RegExpMatcher那樣，呼叫程式可以使用多種輸入、輸出格式，應該考慮如何能夠更方便地滿足它們的需求。

　　值得指出的是，對使用可互換型別對效能的影響進行量化不是一件容易的事兒。如果對呼叫BadRegExpMatcher的程式碼進行分析，它將指派執行時間庫建立輸入用的String物件，這個String物件是為滿足BadRegExpMatcher的需求而生成的。如果要衡量一個元件對效能的真正影響，不僅需要評估程式碼的資源利用情況，還需要評估建立呼叫的程式碼以及呼叫返回的程式碼的資源利用情況，要使用標準的分析工具完成這些分析工作是非常困難的。