StringJavaで印刷できない文字をすべて削除する最速の方法は何ですか？

これまでのところ、138バイト、131文字の文字列で試して測定しました。

• 文字列replaceAll()-最も遅いメソッド
  • 517009結果/秒
• パターンをプリコンパイルしてから、Matcherを使用します replaceAll()
  • 637836結果/秒
• StringBufferを使用し、codepointAt()1つずつ使用してコードポイントを取得し、StringBufferに追加します
  • 711946結果/秒
• StringBufferを使用し、charAt()1つずつ使用して文字を取得し、StringBufferに追加します
  • 1052964結果/秒
• char[]バッファを事前に割り当て、charAt()1つずつ使用して文字を取得し、このバッファを埋めてから、文字列に変換し直します
  • 2022653結果/秒
• char[]古いバッファと新しいバッファの2つのバッファを事前に割り当て、を使用して既存の文字列のすべての文字を一度に取得しgetChars()、古いバッファを1つずつ繰り返し、新しいバッファを埋めてから、新しいバッファを文字列に変換します-私自身の最速バージョン
  • 2502502結果/秒
• 2つのバッファを持つ同じもの-のみを使用しbyte[]、getBytes()エンコーディングを「utf-8」として指定します
  • 857485結果/秒
• 2つのbyte[]バッファを持つ同じものですが、定数としてエンコーディングを指定しますCharset.forName("utf-8")
  • 791076結果/秒
• 2つのbyte[]バッファを持つ同じものですが、エンコーディングを1バイトのローカルエンコーディングとして指定します（ほとんど正気ではありません）
  • 370164結果/秒

私の最善の試みは次のとおりでした：

    char[] oldChars = new char[s.length()];
    s.getChars(0, s.length(), oldChars, 0);
    char[] newChars = new char[s.length()];
    int newLen = 0;
    for (int j = 0; j < s.length(); j++) {
        char ch = oldChars[j];
        if (ch >= ' ') {
            newChars[newLen] = ch;
            newLen++;
        }
    }
    s = new String(newChars, 0, newLen);

それをさらに速くする方法について何か考えはありますか？

非常に奇妙な質問に答えるためのボーナスポイント：「utf-8」文字セット名を使用すると、事前に割り当てられたstaticconstを使用するよりもパフォーマンスが直接向上するのはなぜCharset.forName("utf-8")ですか。

更新

• ラチェットフリークからの提案は、印象的な3105590の結果/秒のパフォーマンス、+ 24％の改善をもたらします！
• Ed Staubからの提案により、さらに別の改善がもたらされます-3471017の結果/秒、以前のベストよりも+ 12％。

アップデート2

私は、提案されたすべてのソリューションとその相互変異を収集するために最善を尽くし、それをgithubで小さなベンチマークフレームワークとして公開しました。現在、17のアルゴリズムを備えています。それらの1つは「特別」です-Voo1アルゴリズム（SOユーザーVooによって提供される）は複雑な反射トリックを採用して恒星の速度を達成しますが、JVM文字列の状態を台無しにするため、個別にベンチマークされます。

ぜひチェックして実行し、ボックスの結果を確認してください。これが私が得た結果の要約です。それは仕様です：

• Debian sid
• Linux 2.6.39-2-amd64（x86_64）
• パッケージからインストールされたJava sun-java6-jdk-6.24-1、JVMはそれ自体を次のように識別します
  • Java（TM）SEランタイム環境（ビルド1.6.0_24-b07）
  • Java HotSpot（TM）64ビットサーバーVM（ビルド19.1-b02、混合モード）

異なるアルゴリズムは、異なる入力データのセットが与えられた場合、最終的に異なる結果を示します。私は3つのモードでベンチマークを実行しました：

同じ単一の文字列

このモードは、StringSourceクラスによって定数として提供されるのと同じ単一の文字列で機能します。対決は次のとおりです。

 Ops /s│アルゴリズム
──────────┼──────────────────────────────
6535947│Voo1
──────────┼──────────────────────────────
5350454│RatchetFreak2EdStaub1GreyCat1
5249343│EdStaub1
50002501│EdStaub1GreyCat1
4859086│ArrayOfCharFromStringCharAt
4295532│RatchetFreak1
4045307│ArrayOfCharFromArrayOfChar
2790178│RatchetFreak2EdStaub1GreyCat2
2583311│RatchetFreak2
1274859│StringBuilderChar
1138174│StringBuilderCodePoint
  994727│ArrayOfByteUTF8String
  918611│ArrayOfByteUTF8Const
  756086│MatcherReplace
  598945│StringReplaceAll
  460045│ArrayOfByteWindows1251

_グラフ形式:( _{出典：greycat.ru）}

複数の文字列、文字列の100％に制御文字が含まれています

ソース文字列プロバイダーは、（0..127）文字セットを使用して大量のランダム文字列を事前に生成しました。したがって、ほとんどすべての文字列に少なくとも1つの制御文字が含まれていました。アルゴリズムは、この事前生成された配列からラウンドロビン方式で文字列を受け取りました。

 Ops /s│アルゴリズム
──────────┼──────────────────────────────
2123142│Voo1
──────────┼──────────────────────────────
1782214│EdStaub1
1776199│EdStaub1GreyCat1
1694628│ArrayOfCharFromStringCharAt
1481481│ArrayOfCharFromArrayOfChar
1460067│RatchetFreak2EdStaub1GreyCat1
1438435│RatchetFreak2EdStaub1GreyCat2
1366494│RatchetFreak2
1349710│RatchetFreak1
  893176│ArrayOfByteUTF8String
  817127│ArrayOfByteUTF8Const
  778089│StringBuilderChar
  734754│StringBuilderCodePoint
  377829│ArrayOfByteWindows1251
  224140│MatcherReplace
  211104│StringReplaceAll

_グラフ形式:( _{出典：greycat.ru）}

複数の文字列、文字列の1％に制御文字が含まれています

以前と同じですが、文字列の1％のみが制御文字で生成されました。他の99％は、[32..127]文字セットを使用して生成されたため、制御文字をまったく含めることができませんでした。この合成負荷は、私の場所でこのアルゴリズムの実際のアプリケーションに最も近いものです。

 Ops /s│アルゴリズム
──────────┼──────────────────────────────
3711952│Voo1
──────────┼──────────────────────────────
2851440│EdStaub1GreyCat1
2455796│EdStaub1
2426007│ArrayOfCharFromStringCharAt
2347969│RatchetFreak2EdStaub1GreyCat2
2242152│RatchetFreak1
2171553│ArrayOfCharFromArrayOfChar
1922707│RatchetFreak2EdStaub1GreyCat1
1857010│RatchetFreak2
1023751│ArrayOfByteUTF8String
  939055│StringBuilderChar
  907194│ArrayOfByteUTF8Const
  841963│StringBuilderCodePoint
  606465│MatcherReplace
  501555│StringReplaceAll
  381185│ArrayOfByteWindows1251

_グラフ形式:( _{出典：greycat.ru）}

誰が最良の答えを提供したかを決めるのは非常に難しいですが、実際のアプリケーションを考えると、Ed Staubによって最良の解決策が与えられ、触発されたので、彼の答えをマークするのは公平だと思います。これに参加してくれたすべての人に感謝します。あなたの意見は非常に役に立ち、非常に貴重でした。ボックスでテストスイートを自由に実行して、さらに優れたソリューションを提案してください（実用的なJNIソリューション、誰か？）。

参考文献

• ベンチマークスイートを備えたGitHubリポジトリ

スレッド間で共有されていないクラスにこのメソッドを埋め込むことが合理的である場合は、バッファーを再利用できます。

char [] oldChars = new char[5];

String stripControlChars(String s)
{
    final int inputLen = s.length();
    if ( oldChars.length < inputLen )
    {
        oldChars = new char[inputLen];
    }
    s.getChars(0, inputLen, oldChars, 0);

等...

現在のベストケースを理解しているので、これは大きな勝利です-20％程度です。

これが潜在的に大きな文字列で使用され、メモリ「リーク」が懸念される場合は、弱参照を使用できます。

1文字の配列を使用すると少しうまくいく可能性があります

int length = s.length();
char[] oldChars = new char[length];
s.getChars(0, length, oldChars, 0);
int newLen = 0;
for (int j = 0; j < length; j++) {
    char ch = oldChars[j];
    if (ch >= ' ') {
        oldChars[newLen] = ch;
        newLen++;
    }
}
s = new String(oldChars, 0, newLen);

そして私は繰り返しの呼び出しを避けました s.length();

動作する可能性のある別のマイクロ最適化は

int length = s.length();
char[] oldChars = new char[length+1];
s.getChars(0, length, oldChars, 0);
oldChars[length]='\0';//avoiding explicit bound check in while
int newLen=-1;
while(oldChars[++newLen]>=' ');//find first non-printable,
                       // if there are none it ends on the null char I appended
for (int  j = newLen; j < length; j++) {
    char ch = oldChars[j];
    if (ch >= ' ') {
        oldChars[newLen] = ch;//the while avoids repeated overwriting here when newLen==j
        newLen++;
    }
}
s = new String(oldChars, 0, newLen);

私の測定によれば、現在の最良の方法（事前に割り当てられた配列を使用したフリークのソリューション）を約30％上回っています。どうやって？私の魂を売ることによって。

これまでの議論に従った人なら誰でも、これが基本的なプログラミングの原則に違反していることを知っていると思いますが、まあまあ。とにかく、以下は文字列の使用された文字配列が他の文字列間で共有されていない場合にのみ機能します-デバッグする必要がある人は誰でもこれを殺すと決定します（substring（）を呼び出さずにこれをリテラル文字列で使用しますJVMが外部ソースから読み取った一意の文字列をインターンする理由がわからないため、これは機能するはずです）。ベンチマークコードがそれを行わないことを確認することを忘れないでください-それは非常に可能性が高く、明らかにリフレクションソリューションに役立ちます。

とにかくここに行きます：

    // Has to be done only once - so cache those! Prohibitively expensive otherwise
    private Field value;
    private Field offset;
    private Field count;
    private Field hash;
    {
        try {
            value = String.class.getDeclaredField("value");
            value.setAccessible(true);
            offset = String.class.getDeclaredField("offset");
            offset.setAccessible(true);
            count = String.class.getDeclaredField("count");
            count.setAccessible(true);
            hash = String.class.getDeclaredField("hash");
            hash.setAccessible(true);               
        }
        catch (NoSuchFieldException e) {
            throw new RuntimeException();
        }

    }

    @Override
    public String strip(final String old) {
        final int length = old.length();
        char[] chars = null;
        int off = 0;
        try {
            chars = (char[]) value.get(old);
            off = offset.getInt(old);
        }
        catch(IllegalArgumentException e) {
            throw new RuntimeException(e);
        }
        catch(IllegalAccessException e) {
            throw new RuntimeException(e);
        }
        int newLen = off;
        for(int j = off; j < off + length; j++) {
            final char ch = chars[j];
            if (ch >= ' ') {
                chars[newLen] = ch;
                newLen++;
            }
        }
        if (newLen - off != length) {
            // We changed the internal state of the string, so at least
            // be friendly enough to correct it.
            try {
                count.setInt(old, newLen - off);
                // Have to recompute hash later on
                hash.setInt(old, 0);
            }
            catch(IllegalArgumentException e) {
                e.printStackTrace();
            }
            catch(IllegalAccessException e) {
                e.printStackTrace();
            }
        }
        // Well we have to return something
        return old;
    }

取得私たTestStringための3477148.18ops/s対2616120.89ops/s古いバリアントのために。それを打ち負かす唯一の方法は、Cで書くこと（おそらくそうではないかもしれません）か、これまで誰も考えていなかったまったく異なるアプローチであると確信しています。タイミングが異なるプラットフォーム間で安定しているかどうかは絶対にわかりませんが、少なくとも私のボックス（Java7、Win7 x64）で信頼できる結果が得られます。

プロセッサの数に応じて、タスクをいくつかの並列サブタスクに分割できます。

私はとても自由で、さまざまなアルゴリズムの小さなベンチマークを作成しました。完璧ではありませんが、ランダムな文字列に対して、特定のアルゴリズムを最低1000回実行します（デフォルトでは約32/200％の印刷不可）。これで、GC、初期化などの処理が必要になります。オーバーヘッドがそれほど多くないため、どのアルゴリズムでも、障害なく少なくとも1回実行する必要はありません。

特に十分に文書化されていませんが、まあ。ここで私達は行く-私は、ラチェットフリークのアルゴリズムと基本的なバージョンの両方が含まれていました。現時点では、200文字の長さの文字列を[0、200）の範囲で均一に分散された文字でランダムに初期化します。

IANAの低レベルのJavaパフォーマンス中毒者ですが、メインループを展開してみましたか？一部のCPUが並行してチェックを実行できるようになる可能性があるようです。

また、これには最適化のためのいくつかの楽しいアイデアがあります。

「utf-8」文字セット名を使用すると、事前に割り当てられた静的const Charset.forName（ "utf-8"）を使用するよりもパフォーマンスが直接向上するのはなぜですか？

あなたが意味する場合String#getBytes("utf-8")など：Charset.forName("utf-8")文字セットがキャッシュされていない場合、これは内部で使用されるため、より良いキャッシュを除いて、より速くなるべきではありません。

1つは、異なる文字セットを使用している（または、コードの一部が透過的に使用している）が、キャッシュされStringCodingている文字セットが変更されていないことです。