stat()
システムコールは本当に高価ですか?使用するのにコストのかかるシステムコールであることをどこかで読みました。本当か?もしそうなら、他の選択肢はありますか?
3 に答える
典型的な設定ではstat(2)
、 、fstat(2)
、およびlstat(2)
が、ファイル情報を取得するための唯一の適切な手法です。パフォーマンスの問題が発生している場合は、アプリケーションのプロファイルを作成して何が起こるかを確認する価値があります。
プロファイリングするには、 でコンパイルしgcc -pg
て実行可能ファイルを実行しgprof(1)
ます。
Qt のようなより大きなライブラリを使用するように切り替えることもできますが、それではパフォーマンスの問題を処理できない可能性が高く、stat(2)
とにかく使用する可能性があります。
したがって、高価であろうとなかろうと、合理的な代替手段はありません。
とはいえ、ジム・マクナマラのコメントにあるように、まさにこれらの理由から高価ではありません. 他に選択肢がないため、glibc と Linux のプログラマーは可能な限りパフォーマンスを向上させました。
問題は、「高価なv / sが必要」として発生します。
Unix 上のすべてのプロセスは、「ユーザー空間」と「カーネル空間」の 2 つのモードで動作し、open()、write()、stat() などのシステム コールが発行されると、プロセスはユーザー空間からカーネル モードに遷移します。高価ですが、このシステムコールで意味のあることを何もしていない場合に限ります。たとえば、stat() を使用してファイルの最終アクセス時刻のみを出力し、それ以上何もしていない場合は、おそらく避けるべきです。
まず、stat() を呼び出す十分な理由があるはずです。次に、コードのさまざまな部分の相対的な実行時間を比較したい場合は、プロファイリング ツールを使用します。これにより、正確な統計を提供して、どの関数呼び出しが高価で、どれが高価でないかを証明できます。