0

std::string潜在的に大きなものから多くの小さな s を解析する必要がある状況がありますstd::string(私は 20M でストレステストを行っていますstd::string)。std::string解析したいの先頭のインデックスを追跡し、末尾に到達しstd::stringたらsubstr大きなstd::string. 次に、std::string解析したこれらの を a のキーとして使用しますstd::map。

に切り替えることで、これをより高速に実行できるようにしていchar*ます。私が収集する必要があるのは、解析したい文字列の先頭へのポインターを維持し、解析しながら文字列の長さを数え、char*解析された文字列の長さを保持する新しいインスタンスを作成することです。次にstrncpy/memcpy、文字列を新しいchar*. この newchar*を a のキーとして使用する場合、 astd::mapを実行する比較ファンクターを提供する必要がありstrcmpます。

私が今持っている方法では、文字列を挿入せずに解析するのに平均で合計290ミリ秒かかりますstd::map（挿入すると合計で約450ミリ秒かかります）。char*大幅に (50 ミリ秒以上) 良い結果が得られるように切り替えることはできますか?

4

1 に答える 1

3

第一に、誰も試さずに本当の答えを知らないので、自分で試してみるのもよいでしょう。しかし第二に、私たちは知識に基づいた推測をすることができます：おそらくそうではありません。std::stringとにかく、それはすべて内部で行っています。

すべきことは、既存の文字列内の範囲を表すクラスを作成し（つまり、イテレーターのペアを格納し）、このクラスをマップのインデックスとして使用することです。このようにして、小さな文字列の束を割り当てることを回避できます。これは、少なくともロード中に、パフォーマンスヒットのほとんどが発生する場所であることがほぼ確実です。次に、ソース文字列をメモリに保持するだけで、イテレータは引き続き有効です。

主にルックアップを実行するかどうかも検討unordered_mapできます（現在は不変の文字列を使用しているため、ハッシュの結果をキャッシュできます）が、これが高速になるかどうかを知る唯一の方法は、すべてのパフォーマンスの問題に対して同じ方法です。 ：テストとデータ。

于 2013-01-09T01:52:32.303 に答える