| 技術 | 時間（單位：納秒） |
|---|---|
String |
69，809，420 |
StringBuffer |
251，652，393 |
Rope.charAt |
79，441，772，895 |
Rope.iterator |
1，910，836，551 |
用來得到表 2 中符合預期的結果的 rope，是通過對初始字符串執行一系列復雜的變換之后創建的。但是，如果直接從字符序列創建這個 rope 而不進行變換，那么性能數字會產生較大的變化。表 3 比較了兩種方法的性能。這次是在一個包含 182，029 個字符的 rope 上迭代，這次的 rope 是直接用包含 Project Gutenberg 版查理斯·狄更斯 圣誕歡歌的字符數組初始化的。
| 技術 | 時間（單位：納秒） |
|---|---|
String |
602，162 |
StringBuffer |
2，259，917 |
Rope.charAt |
462，904 |
Rope.iterator |
3，466，047 |
如何用我前面的理論討論解釋這一性能逆轉呢？ rope 的構建是個關鍵因素：當直接使用底層的 CharacterSequence或字符數組構建 rope 時，它只有一個簡單的結構，里面包含一個扁平 rope。因為這個 rope 不包含連接或子串節點，所以字符查詢操作要么直接委托給底層序列的 charAt方法（在 CharacterSequence的情況下），要么包含進行數組查詢（在數組的情況下）。扁平 rope 的 Rope.charAt性能與底層表示的 chatAt 性能匹配，通常是 O（1）；所以性能是不同的。
聰明的讀者可能想知道既然大家都提供 0（1）的訪問時間，為什么 charAt會比迭代器快 7 倍。這個區別是因為在 Java 語言中，Iterator必須返回 Object。而 charAt實現直接返回 char原語，迭代器實現必須將每個 char裝箱為一個 Character對象。自動裝箱可能消除了原語裝箱在語法上的麻煩，但是不能消除性能上的損失。
后，非常明顯的是：Rope.charAt的性能比 String.charAt的性能好。原因是 Rope使用專門的類來表示延遲子串（lazy substring），因此使普通 rope 的 charAt的實現保持簡單。對比之下，Java SE 的 String實現使用同一個類表示常規字符串和延遲子串，因此多多少少將 charAt的邏輯弄得復雜起來，所以在迭代常規字符串期間增加了少量性能開支。
在討論 rope 上的正則表達式搜索性能的優化時，還會提到 Rope 迭代。
用 Rope.write 對輸出進行優化
在某種程度上，多數 rope 實例都必須寫入到某些位置，通常寫到一個流內。不幸的是，將對象寫入流要調用對象的 toString方法。這種序列化方式強行在寫入一個字符之前在內存中建立整個對象的字符串表示，對于大型對象來說，這是個非常大的性能拖累。Ropes for Java 設計的時候考慮了大型的字符串對象，所以它提供了更好的方式。
為了提高性能，Rope引入了一個 write 方法，接受一個 Writer和一個范圍說明，然后將 rope 的指定范圍的字符寫到 writer。這樣節省了用 rope 構建 String的時間和內存開支，對于大型 rope 來說，這種開支是相當巨大的。清單 4 顯示了 rope 輸出的標準方式和增強方式。
清單 4. Rope輸出的兩種方式
out.write(rope);
rope.write(out);
表 4 包含的測評結果是將一個長度為 10，690，488、深度為 65 的 rope 寫入一個由內存緩沖區支持的流的結果。請注意，只顯示了節省的時間，但是在臨時分配的堆空間上的節省也非常巨大。
| 技術 | 時間（單位：納秒） |
|---|---|
out.write |
75，136，884 |
rope.write |
13，591，023 |
變換性能測評
Rope 的變換從理論上要比使用連續字符的字符串表示方式快得多。但反過來，正如所看到的，rope 的迭代變慢了。在這一節，將看到 Ropes for Java 和 String、StringBuffer進行變換操作的性能測評比較。
全部測試都用 Project Gutenberg 版本的電子書 圣誕歡歌初始化（182，029 個字節），并對其連續應用一系列變換。在多數情況下，變換的數量在 20 到 480 的范圍內變動，以便演示數據結構縮放的效果。（圖 2、3、4 將變換的數量稱為 計劃長度（plan length）。）每個測試執行了七次，并使用中間結果。
插入性能測評
在插入測評中，從前一次迭代的輸出中隨機選擇一個子串，然后插入到字符串的隨機位置。圖 2 顯示了測評的結果。
對 String和 StringBuffer來說，完成測評所需要的時間隨著計劃長度的增加呈指數級增長。相比之下，Rope 則執行得極好。
附加字符串性能評測
