ウィキペディアから：
主な欠点は、全体的なスペース使用量が多く、インデックス作成が遅いことです。どちらも、ツリー構造が大きくなり、深くなるにつれて、より深刻になります。ただし、インデックス作成の実際のアプリケーションの多くは、文字列の反復のみを含みます。これは、リーフノードがキャッシュ効果の恩恵を受けるのに十分な大きさである限り高速のままです。
ロープとストリングの間にある種の妥協点を実装しています。基本的にはロープだけですが、連結された文字列が短い場合に連結オブジェクトを文字列に平坦化する点が異なります。これにはいくつかの理由があります。
- 連結された文字列が短い場合、連結オブジェクトの利点は最小限に抑えられます（2つの文字列を通常の形式で連結するのにそれほど時間はかかりません）。
- これを行うと、木の大きさ/深さが減少します（ロープの欠点が減少します）。
- これを行うと、リーフノードのサイズが大きくなります（キャッシュをより有効に活用するため）。
ただし、長さが長くなるとロープのメリットも少なくなるので、妥協点を見つけたいと思います。「スイートスポット」は、論理的には「リーフノードがキャッシュ効果の恩恵を受けるのに十分な大きさ」の周りにあるように見えます。問題は、それがどれくらい大きいかわからないということです。
編集：私がこれを書いている間、理想的なサイズはキャッシュページのサイズであることに気づきました。それは、ロープが文字列でとにかく発生する場合にのみキャッシュミスを引き起こすためです。だから私の2番目の質問は、この推論は正しいですか？また、キャッシュページのサイズを検出するクロスプラットフォームの方法はありますか？
私の目標言語はC++です。