кеширование localtime_r () оно того стоит?

Question

стоит ли хранить локальную копию struct tm и обновлять ее только при необходимости;ниже func не является потокобезопасным ... также я видел, что можно сэкономить только 6-7% процессорного времени ...

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);
}

Дополнительные сведения: - мое приложение выполняет звонки со скоростью более 3000 в секундуlocaltime_r()

обнаружил как минимум 33% экономии времени процессора, когда я кеширую строки меток времени в формате "2011-12-09 10:32:45" againt time_t секунд

спасибо всем nos, asc99c иМирча.

Answer 1

Я бы, наверное, упомянул скорость вызова 3000 / с в вашем вопросе!Сделай это.Недавно я профилировал поколение экрана, который вызывал локальное время примерно 1 000 000 * 10 000 раз.

Вложенные циклы можно было бы существенно улучшить, если немного подумать, но то, что я увидел, составляло около 85% процессорного временииспользуется по местному времени.Простое кэширование результата, чтобы он вызывался только 10 000 раз, сокращало 85% времени генерации страниц, и это делало его достаточно быстрым.

Answer 2

«Избегать вызова библиотечной функции, которая на самом деле не нужна» того стоит. Остальное - только ваш компромисс между памятью и скоростью.

Поскольку вы вызываете эту 3000 / секунду, вы можете пойти еще дальше и поместить эту функцию как static inline в заголовок, а также (если используете GCC) использовать подсказки прогнозирования ветвления для условного выражения, заявив, что его получение "маловероятно":

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