1

今日、いくつかのタイミングコードで遊んでいたところ、文字列リテラルをstd :: stringに割り当てると、約10％高速であることがわかりました（12文字の短い文字列の場合、大きな文字列の場合はさらに大きな違いがあります）。 （sizeof演算子を使用して）既知の長さのリテラルを使用します。（VC9コンパイラでのみテストされているので、他のコンパイラの方がうまくいくと思います）。

std::string a("Hello World!");
std::string b("Hello World!", sizeof("Hello World!");//10% faster in my tests

さて、私が疑う理由は、文字列の長さを取得するためにstrlenを呼び出さなければならないためです（VC9は私の強みではないため、100％確実ではありません）。その後、2番目の場合と同じようにします。

std :: stringが存在していた期間と、最初のケースが実際のプログラムでどれほど一般的であるか（特に、+、=、+ =などの演算子と同等のメソッドを含める場合）を考えると、どうして最初のケースが最適化されないのでしょうか。 2番目に？std :: basic_stringオブジェクトであり、リテラルであるかどうかを言うのも非常に単純なようです。bのように記述されているかのようにコンパイルしますか？

4

2 に答える 2

4

最初のものを2番目に最適化することはできません。最初の例では、文字列の長さが不明であるため計算する必要があります。2番目の例では、文字列の長さを指定するため、計算は必要ありません。

また、sizeof（）を使用しても違いはありません。これは、コンパイル時にも計算されます。最初のケースで使用されるコンストラクターは次のとおりです。

 string( const char * s );

このコンストラクターが文字列リテラルが与えられていることを検出する方法はありません。コンパイル時にその長さを計算することははるかに少ないです。

また、Cスタイルの文字列リテラルから文字列を作成することは、実際のコードでは比較的まれにしか発生しません。最適化する価値はありません。また、最適化する必要がある場合は、次のように書き直してください。

while( BIGLOOP ) {
   string s( "foobar" );
   ...
}

なので：

string f( "foobar" );
while( BIGLOOP ) {
   string s( f );
   ...
}
于 2010-01-31T23:00:06.863 に答える