用來得到表 2 中符合預(yù)期的結(jié)果的 rope，是通過對初始字符串執(zhí)行一系列復(fù)雜的變換之后創(chuàng)建的。但是，如果直接從字符序列創(chuàng)建這個 rope 而不進行變換，那么性能數(shù)字會產(chǎn)生較大的變化。表 3 比較了兩種方法的性能。這次是在一個包含 182，029 個字符的 rope 上迭代，這次的 rope 是直接用包含 Project Gutenberg 版查理斯·狄更斯 圣誕歡歌的字符數(shù)組初始化的。

如何用我前面的理論討論解釋這一性能逆轉(zhuǎn)呢？ rope 的構(gòu)建是個關(guān)鍵因素：當(dāng)直接使用底層的 CharacterSequence或字符數(shù)組構(gòu)建 rope 時，它只有一個簡單的結(jié)構(gòu)，里面包含一個扁平 rope。因為這個 rope 不包含連接或子串節(jié)點，所以字符查詢操作要么直接委托給底層序列的 charAt方法（在 CharacterSequence的情況下），要么包含進行數(shù)組查詢（在數(shù)組的情況下）。扁平 rope 的 Rope.charAt性能與底層表示的 chatAt 性能匹配，通常是 O（1）；所以性能是不同的。

聰明的讀者可能想知道既然大家都提供 0（1）的訪問時間，為什么 charAt會比迭代器快 7 倍。這個區(qū)別是因為在 Java 語言中，Iterator必須返回 Object。而 charAt實現(xiàn)直接返回 char原語，迭代器實現(xiàn)必須將每個 char裝箱為一個 Character對象。自動裝箱可能消除了原語裝箱在語法上的麻煩，但是不能消除性能上的損失。

后，非常明顯的是：Rope.charAt的性能比 String.charAt的性能好。原因是 Rope使用專門的類來表示延遲子串（lazy substring），因此使普通 rope 的 charAt的實現(xiàn)保持簡單。對比之下，Java SE 的 String實現(xiàn)使用同一個類表示常規(guī)字符串和延遲子串，因此多多少少將 charAt的邏輯弄得復(fù)雜起來，所以在迭代常規(guī)字符串期間增加了少量性能開支。

在討論 rope 上的正則表達式搜索性能的優(yōu)化時，還會提到 Rope 迭代。

用 Rope.write 對輸出進行優(yōu)化

在某種程度上，多數(shù) rope 實例都必須寫入到某些位置，通常寫到一個流內(nèi)。不幸的是，將對象寫入流要調(diào)用對象的 toString方法。這種序列化方式強行在寫入一個字符之前在內(nèi)存中建立整個對象的字符串表示，對于大型對象來說，這是個非常大的性能拖累。Ropes for Java 設(shè)計的時候考慮了大型的字符串對象，所以它提供了更好的方式。

為了提高性能，Rope引入了一個 write 方法，接受一個 Writer和一個范圍說明，然后將 rope 的指定范圍的字符寫到 writer。這樣節(jié)省了用 rope 構(gòu)建 String的時間和內(nèi)存開支，對于大型 rope 來說，這種開支是相當(dāng)巨大的。清單 4 顯示了 rope 輸出的標準方式和增強方式。

清單 4. Rope輸出的兩種方式
    
 out.write(rope);
 rope.write(out);

表 4 包含的測評結(jié)果是將一個長度為 10，690，488、深度為 65 的 rope 寫入一個由內(nèi)存緩沖區(qū)支持的流的結(jié)果。請注意，只顯示了節(jié)省的時間，但是在臨時分配的堆空間上的節(jié)省也非常巨大。

變換性能測評

Rope 的變換從理論上要比使用連續(xù)字符的字符串表示方式快得多。但反過來，正如所看到的，rope 的迭代變慢了。在這一節(jié)，將看到 Ropes for Java 和 String、StringBuffer進行變換操作的性能測評比較。

全部測試都用 Project Gutenberg 版本的電子書 圣誕歡歌初始化（182，029 個字節(jié)），并對其連續(xù)應(yīng)用一系列變換。在多數(shù)情況下，變換的數(shù)量在 20 到 480 的范圍內(nèi)變動，以便演示數(shù)據(jù)結(jié)構(gòu)縮放的效果。（圖 2、3、4 將變換的數(shù)量稱為 計劃長度（plan length）。）每個測試執(zhí)行了七次，并使用中間結(jié)果。

插入性能測評

在插入測評中，從前一次迭代的輸出中隨機選擇一個子串，然后插入到字符串的隨機位置。圖 2 顯示了測評的結(jié)果。

對 String和 StringBuffer來說，完成測評所需要的時間隨著計劃長度的增加呈指數(shù)級增長。相比之下，Rope 則執(zhí)行得極好。

附加字符串性能評測