2

テキストファイルに保存されているオブジェクトを逆シリアル化する既存のコードを使用しています（これらの数千万を読み取る必要がある可能性があります）。ファイルの内容は最初にに読み込まれ、wstring次にそこから作成wistringstreamされます。プログラムでVerySleepyプロファイラーを実行すると、その時間の約20％が次の呼び出しスタックに費やされていることがわかります。

Mtxlock or RtlEnterCritialSection
std::_Mutex::_Lock
std::flush
std::basic_istream<wchar_t, std::char_traits<wchar_t> >::get
<rest of my program>

および同様のものstd::_Mutex::_Unlock。Visual C++2008を使用しています。

を見ると、基になる。を呼び出してメソッドを実行istreamするオブジェクトを構築していることがわかります。これにより、そのバッファに関連付けられた呼び出しが行われます。これらは次のように定義されます。sentry_Lock_Unlockbasic_streambuf_Lock_Unlock_Mutex

#if _MULTI_THREAD
    // actually defines non-empty _Lock() and _Unlock() methods
#else /* _MULTI_THREAD */
    void _Lock()
    {   // do nothing
    }

void _Unlock()
    {   // do nothing
    }
#endif /* _MULTI_THREAD */

_MULTI_THREADが次のように設定されているようyvals.hです

#define _MULTI_THREAD   1   /* nontrivial locks if multithreaded */

これで、このバッファにアクセスしようとする別のスレッドが存在しないことはわかっていますが、標準のiostreamを使用している間は、このロックを回避する方法がないように見えます。これは奇妙でイライラするようです。私は何かが足りないのですか？これに対する回避策はありますか？

4

3 に答える 3

1

プロジェクト プロパティ、C/C++、コード生成でランタイム ライブラリの値を確認します。マルチスレッドの場合は、非マルチスレッド バージョンに変更します。

Visual C++ 7.1 (!) 以降のどのバージョンでも、マルチスレッド CRT が削除されているため運が悪く、スタックしています。

于 2011-04-28T17:42:29.250 に答える
0

あなたのstd::flush場合は無意味に思えます。をフラッシュする方法がわからないistreamので、の結果だと思いますtie。ネクタイを外したい場合があります。つまり、を呼び出しtie(NULL)ますwistringstream。これにより、取得するロックの数も減るはずです。

于 2011-04-29T08:09:53.940 に答える
0

次のようなものを置き換えることで、基礎となるバッファに直接アクセスすることが判明しました

c = _text_in->get();

このようなもので

c = _text_in->rdbuf()->sbumpc();

問題を修正し、パフォーマンスを大幅に向上させました。

于 2011-04-29T15:59:32.517 に答える