0

検索エンジンに入力するプロセスの一環として、Berekely-DB 値ストアにも入力します。このプロセスは毎晩繰り返され、現在、毎晩の総実行時間の +/- 60% は、値ストアに挿入される値を作成することによって発生します (したがって、Berekely-DB への実際の挿入と発生した時間は除外されます)。 Berekely クライアントによる

これらの値は、各キーに stringbuilder を割り当て、そのような stringbuilder に平均で約 1000 個の文字列を追加することによって作成されます。結果の平均値は約 10k です。次のことを考えると、これをより効率的に行うことができるかどうか疑問に思っています。文字列は末尾に追加されます。

たとえば、stringbuilder を char[] または characterStream / writer に交換すると、パフォーマンスが向上しますか? そうすれば、char[] に書き込む場所を保持してインデックスを付けることができます。

ありがとう、Geert-Jan

4

4 に答える 4

5

サイズ変更の量を減らすために、より高い初期容量で文字列ビルダーを作成できます。つまり、次のことができるコンストラクターがあります。

int SIZE=10000;
StringBuilder b = new StringBuilder(SIZE);

手動で char[] とインデックスをジャグリングしても、これはあまり改善されないことが予想されます。これは、StringBuilder が既に行っていることだからです。

于 2009-11-17T17:53:12.673 に答える
0

これらの 1000 の文字列はどこから来ているのですか? これらの 1000 個のオブジェクトの作成時間が、StringBuilder の償却された拡張に必要な時間を完全に小さくしているとは信じがたいです。

于 2009-11-17T19:37:54.043 に答える
0

リビジョン III:

StringBuilders での文字列の連結に異常に長い時間がかかる場合は、メモリがいっぱいになっている可能性があります。したがって、私たちの目標は、大量のメモリを消費することなく文字列連結を実現することです。CPU 時間の節約が自動的に続くことを願っています。

私の計画は次のようになりました。これらの部分文字列を長い StringBuilder に連結する代わりに、それらの (既存の) 文字列への参照のリストを作成できます。参照のリストは部分文字列の合計よりも短くする必要があるため、メモリの消費量が少なくなります。

その大きな文字列を格納するときが来て初めて、パーツを 1 つの大きな StringBuilder に連結し、文字列を取り出し、文字列を格納し、文字列への参照を破棄し、StringBuilder をクリアして、繰り返します。これは素晴らしい解決策だと感じました！

ただし、 2002 年のこの記事によると、配列内の String 参照は、おそらく ArrayList 内でも同様に、なんと 8 バイトを使用します。 最近の StackOverflow の投稿では、これがまだそうであることが確認されています。したがって、10 バイトの文字列への参照のリストは、文字列ごとに 2 バイトしか節約できません。したがって、同様の問題の可能性として私の「解決策」を提示しますが、この特定の問題がそれから恩恵を受けることができるとは思いません。

于 2009-11-18T08:21:52.273 に答える
0

ロープを試してみてください。このサイトは詳細が不足していますが、より良い説明と追加パフォーマンスを比較するいくつかの優れたベンチマークを備えた素晴らしい記事がここにあります。

私は実際にロープパッケージを使用したことがなく、十分な言い訳がありませんでした. しかし、有望に見えます。

編集：追加のベンチマーク情報

PerformanceTestロープの記事からクラスをダウンロードし、に加えて のテストをStringBuilder追加しましたStringBuffer。のパフォーマンスの向上はStringBuilder無視できるようです。

ロープの記事からテスト コードをダウンロードし、テストを変更して と を含めStringBuilderましStringBufferた。

追加計画の長さ: 260
[StringBuilder] 平均 = 117,146,000 ns 中央値 = 114,717,000 ns
[StringBuffer] 平均 = 117,624,400 ns 中央値 = 115,552,000 ns
[ロープ] 平均 = 484,600 ns 中央値 = 483,000 ns

追加計画の長さ: 300
[StringBuilder] 平均 = 178,329,000 ns 中央値 = 178,009,000 ns
[StringBuffer] 平均 = 217,147,800 ns 中央値 = 216,819,000 ns
[ロープ] 平均 = 252,800 ns 中央値 = 253,000 ns

追加計画の長さ: 500
[StringBuilder] 平均 = 221,356,200 ns 中央値 = 214,435,000 ns
[StringBuffer] 平均 = 227,432,200 ns 中央値 = 219,650,000 ns
[ロープ] 平均 = 510,000 ns 中央値 = 507,000 ns

StringBuilder と StringBuffer の違いはそれほど大きくありません。目の前のタスクでは、ここではロープが明らかに勝っているように見えます.

于 2009-11-18T02:47:23.213 に答える