localtime_r（）をキャッシングする価値はありますか？

ローカルコピーをstruct tmのままにしておき、必要な場合にのみ更新してください。 FUNC以下のスレッドセーフではありません...また、私はlocaltime_r（）をキャッシングする価値はありますか？

struct tm* custom_localtime (time_t now_sec) 
{ 

    static time_t cache_sec; 
    static struct tm tms; 

    if (now_sec != cache_sec) { 
     cache_sec = now_sec; 
     localtime_r(&cache_sec, &(tms)); 
    } 

    return(&tms); 
}

追加の詳細... CPU時間のわずか6〜7％を保存することができます見てきました： - 私のアプリは3000以上/秒に呼び出しを行います

localtime_r()は、私はあなたにすべての番号、asc99cとミルチャに感謝time_t秒

againt形式 "2011-12-09 10:32:45"のタイムスタンプ文字列をキャッシュしたときに保存し、少なくとも33％のCPU時間を見つけました。

出典

2011-09-15 SparKot

あなたの合理性の基準は何ですか？ – Jon

ログを書き込むために3000 /秒以上のlocaltime_r（）を呼び出すシナリオで時間を節約するために... – SparKot

あなたに問題を保存する時間があれば、それをしてください。それが問題でなければ、しないでください。違いが*あなた*に重要であるかどうか*私たち*決定することができますか？ – Jon

私はたぶんあなたの質問で3000/sのコールレートを言いました！それをやりなさい。私は最近、ローカルタイムを約1,000,000×10,000回と呼んでいたスクリーンの生成をプロファイリングしていました。

ネストされたループは少し考えても大幅に改善されましたが、CPU時間の約85％がローカルタイムで使用されていました。単に結果を1万回呼び出されるようにキャッシングするだけで、ページ生成の85％をカットして、それを簡単に十分に速くしました。

出典

2011-09-15 10:54:54 asc99c

"実際には必要ないライブラリ関数呼び出しを避ける"というのは価値があります。残りの部分は、メモリと速度のトレードオフだけです。

これを3000秒間呼び出すので、この関数をヘッダにstatic inlineと入れておき、条件付き分岐予測ヒントを使用して（GCCを使用している場合）「可能性はありません」：

if (__builtin_expect(now_sec != cache_sec, 0))

出典

2011-09-15 08:00:10 Mircea

localtime_r（）をキャッシングする価値はありますか？

答えて

関連する問題