私は、NULL文字列を表すために、いくつかの独自のものを受け取り、それを解析し、(メッセージを表すクラスに埋め込まれた)静的なchar配列の束を作成するレガシーコードを持っています。その後、文字列へのポインターがすべて渡され、最終的に何らかのバッファーにシリアル化されます。
プロファイリングは、str*()メソッドに多くの時間がかかることを示しています。
ですので、可能であれば利用したいと思いmemcpy()ます。それを達成するには、長さを NULL 終端文字列へのポインタに関連付ける方法が必要です。私は考えました：
メモリの割り当てとスレッドの同期が必要なため、使用std::stringすると効率が悪くなります。
使えますstd::pair<pointer to string, length>。しかし、この場合、「手動で」長さを維持する必要があります。
どう思いますか？
プロファイリングは、str*() メソッドに多くの時間がかかることを示しています
確かにそうです...どのアレイでも操作するには多くの時間がかかります。
したがって、可能であれば memcpy() を使用したいと思います。それを達成するには、長さを NULL 終端文字列へのポインタに関連付ける方法が必要です。私は考えました：
memcpyより遅くはありませんstrcpy。実際、あなたが行っているstrlen量を特定するために a を実行するとmemcpy、strcpyほぼ確実に速くなります。
std::string を使用すると、メモリの割り当てとスレッドの同期が必要になるため、効率が悪いように見えます
効率が悪いように見えるかもしれませんが、それに取り組んできたあなたや私のものよりも優れた頭脳がたくさんあります
std::pair を使用できます。しかし、この場合、「手動で」長さを維持する必要があります。
これは、長さの計算にかかる時間を節約する 1 つの方法です。明らかに、手動で長さを維持する必要があります。これは、windows がBSTR効果的に機能する方法です (ただし、長さはメモリ内で実際の文字列データの直前に格納されます)。 std::string. たとえば、すでにこれを行っています...
どう思いますか？
あなたの質問はひどく聞かれると思います。答えをほぼ不可能にする実際の質問はありません。今後は具体的な質問をすることをお勧めします。
使用するstd::string
を使用しstd::stringます。すでに与えられたアドバイスですが、その理由を説明しましょう。
1 つは、カスタム メモリ割り当てスキームを使用することです。あなたのchar*文字列はおそらくmallocされています。つまり、それらは最悪の場合に整列されていることを意味し、実際には . には必要ありませんchar[]。std::string不必要な調整に悩まされることはありません。さらに、一般的な実装でstd::stringは、ヒープ割り当てを完全に排除し、参照の局所性を向上させる「小さな文字列の最適化」を使用します。文字列のサイズは、それ自体と同じキャッシュ ラインにありchar[]ます。
2 つ目は、文字列の長さを維持することです。これは実際に速度の最適化です。ほとんどのstr*関数は、この情報を前もって持っていないため遅くなります。
2 番目のオプションはrope、SGI などのクラスです。これは、一部の文字列のコピーを削除することでより効率的になります。
str*()あなたの投稿は、関数呼び出しがどこから来ているのかを説明していません。通り過ぎることはchar *確かにそれらを呼び出しません。文字列操作を実際に行っているサイトを特定し、それらが非効率的に行っているかどうかを調べます。よくある落とし穴の1つは、strcat最初に宛先文字列をスキャンして終了0文字を探す必要があることです。連続して複数回呼び出すstrcatと、O（N ^ 2）アルゴリズムになってしまう可能性があるため、注意が必要です。
で置き換えstrcpyてmemcpyも、大きな違いはありません。strcpy文字列の長さを見つけるために余分なパスを実行するのではなく、単に（概念的には！）文字ごとのコピーであり、終了する0に遭遇すると停止します。これは、よりもはるかに高価ではなくmemcpy、常にstrlen続くよりも安価です。によってmemcpy。
文字列操作のパフォーマンスを向上させる方法は、可能な限りコピーを回避することです。コピーを高速化することを心配する必要はありません。代わりに、コピーを少なくしてください。そして、これは、、、、、またはカスタムの文字列/配列クラスであるかどうかに関係なく、すべての文字列（および配列）の実装に当てはまります。char *std::stringstd::vector<char>
私はどう思いますか？事前最適化に夢中になっている他の人がしていることを、あなたもすべきだと思います。最もあいまいで、保守が困難でありながら、直感的に (とにかくあなたにとって) 高性能な方法を見つけて、その方法で実行する必要があります。あなたpair<char*,len>はmalloc/memcpyのアイデアで何かに取り組んでいるようです。
何をするにしても、メンテナンスを容易にする既存の最適化されたホイールを使用しないでください。直観的に測定されたパフォーマンスの向上に夢中になっている場合、メンテナンス可能であることは、想像を絶する最も重要なことではありません。さらに、よく知られているように、コンパイラとその標準ライブラリの実装を作成した人よりもかなり賢いです。何かについて彼らの判断を信頼するのは、あなたが真剣にばかげているほどです。パフォーマンスが向上するため、自分で全体を書き直すことを検討する必要があります。
そして...最後にやりたいことは、プロファイラーを使用して直感をテストすることです。それは科学的で几帳面すぎるでしょう。私たちはまた、個人の直感と啓示が決して間違いではないことも知っています。状況の様子を直感的に把握しているのに、客観的なツールで測定する時間を無駄にする必要はありません。
ここでの私の意見は 100% 正直であることを心に留めておいてください。私の体には皮肉な骨がありません。