Comments 6
Это специально "под ChatGPT" стилизовано? :)
это скорее стилизовано под массу комментариев к моей предыдущей статье об асинхронном логировании, latency, quill. какие-то рассуждения в статье кажутся спорными?
Только индусской подход. Если работает медленно не разбираться в причинах, а засунуть в другой поток. Создав при этом массу новых проблем. Учитывая, что в логировании масса подходов позволяющих решить проблему, насколько это возможно. Все остальное решается на уровне архитектуры.
Я как раз и не продвигаю какой-то из подходов. Мою задачу я видел в том чтобы обсудить какие вообще есть варианты и какие у них trade-offs
Асинхронное логирование само по себе не является "индусским подходом". Это нормальный инструмент, который решает вполне конкретную задачу - минимизацию latency в вызывающем потоке, когда важно не блокироваться ни на I/O, ни на форматировании
Да, у него есть своя цена и ограничения. Но и у альтернативных подходов они тоже есть
В итоге это не вопрос «правильно / неправильно», а вопрос требований и архитектуры
Ужасно. Пишите дальше.
Я, если честно, так и не понял что на самом деле ограничивает производительность. Думал на конкретных примерах расскажут.
Ну вот посчитали мы, что bottleneck это вывод в консоль. Перенесли в отдельный поток. Теперь bottleneck это синхронизация с этим потоком, а там еще и очередь копится. Делать то что, просто меньше логировать?
Асинхронное логирование в C++ — не серебряная пуля: что на самом деле ограничивает производительность