При проектировании файлового логгера существует два основных сценария с точки зрения оптимизации.
- Либо сообщение попадет в файл
- Или не будет.
Если сообщение необходимо отправить в файл, а файл не находится на твердотельном диске, можно ожидать, что скорость диска будет доминировать во всем процессе. У вас будет сложный компромисс между записью на диск после каждой строки журнала, что означает, что время, потраченное на создание сообщения журнала, будет незначительным во всех простых случаях; или не сбрасывать, что означает, что вы потеряете самые ценные журналы. Вы потеряете их из-за редких, трудно воспроизводимых сбоев системы или приложения.
Все широко используемые каркасы журналирования позволяют настраивать сброс, передавая решение приложению или даже его администратору.
Если сообщение не попадает в файл (например, из-за текущих настроек уровня журнала), для производительности важно определить этот факт (сравнить уровни журнала) до текста создается сообщение журнала (форматирование параметров, форматирование меток времени ...).
snprintf хорошо, но убедитесь, что вы вызываете его только тогда, когда вам действительно понадобится отформатированное сообщение.
Наконец, сложно получить наносекундную точность. Это также бессмысленно, потому что, как вы уже измерили, это часть отдельной инструкции CPU на вашем оборудовании; Вы должны были бы стать очень формальными о том, какой момент - тот, который будет отмечен. У вас есть выбор между использованием системного времени (обновляется примерно 100 раз в секунду, в зависимости от вашей операционной системы), значением ticks , не синхронизированным с реальным временем, или счетчиком меток времени ЦП. Последний метод никоим образом не синхронизируется и не преобразуется в реальное время, поэтому он не очень практичен для ваших нужд. Читайте здесь, почему .
Всегда лучше, если вы печатаете временные метки только с разрешением, которое известно , и значение которого существенно не изменяется во время создания сообщения журнала.