まず、ご意見ありがとうございます。先週末、私は改訂されたプログラムを使用して実際のデータを用いてストレステストを実施しました。そして、私の問題が解決されたことを嬉しく思います(A.J.^_ ^)。私は私の発見を共有したいと思います。
A.J.の例を勉強した後、私はStringTokenizerと "indexOf"(Regexは私の状況ではStringTokenizerと比較してさらに悪い)を使ってデータを読み込んで処理するいくつかのテストプログラムを実行しました。私のテストプログラムは、24メッセージ(それぞれ〜12000トークン)を処理するために必要なミニ秒数を数えます。
StringTokenizerは〜2700msが必要で、 "indexOf"は〜210msしかかかりません!
私はその後、(最小限の変更で)このように私のプログラムを改訂し、最後の週末、実ボリュームでテストしてみた:
オリジナルプログラム:
public class MsgProcessor {
//Some other definition and methods ...
public void processMessage (String msg)
{
//...
StringTokenizer token = new StringTokenizer(msg, FieldSeparator);
while (token.hasMoreTokens()) {
my_data = token.nextToken();
// peformance different action base on token read
}
}
}
そして、ここで使用してプログラムを更新されます"のindexOf":
public class MsgProcessor {
//Some other definition and methods ...
private int tokenStart=0;
private int tokenEnd=0;
public void processMessage (String msg)
{
//...
tokenStart=0;
tokenEnd=0;
while (isReadingData) {
my_data = getToken(msg);
if (my_data == null)
break;
// peformance different action base on token read ...
}
}
private String getToken (String msg)
{
String result = null;
if ((tokenEnd = msg.indexOf(FieldSeparator, tokenStart)) >= 0) {
result = msg.substring(tokenStart, tokenEnd);
tokenStart = tokenEnd + 1;
}
return result;
}
}
- 元のトークンには "null"データがないことに注意してください。 FieldSeparatorが見つからない場合、「getToken(msg)」はnullを返します(「トークンをもう使用しない」というシグナルとして)。
StringTokenizerで、あなたがやっていることではないと確信していますか?問題を示す短くしかし完全なプログラムを示してください。 –
私はそうは思わない。文字列はランダムアクセスです。長い文字列の場合は減速しません。 – Thilo
'StringTokenizer'には、長い入力に対して爆発するものはありません。それは周囲のコードの何かでなければなりません。 – Barend