Библиотека журналов для (c ++) игр [закрыто]


15

Я знаю много библиотек журналов, но не много их тестировал. (GoogleLog, Pantheios, грядущий импульс :: библиотека журналов ...)

В играх, особенно в удаленных многопользовательских и многопоточных играх, ведение журнала является жизненно важным для отладки, даже если вы удалите все журналы в конце.

Допустим, я делаю компьютерную (не консольную) игру, в которой нужны логи (многопользовательские, многопоточные и / или многопроцессные), и у меня есть веские причины искать библиотеку для логов (например, у меня нет времени или я не уверен в моей способности написать один правильно для моего случая).

Предполагая, что мне нужно:

  1. производительность
  2. простота использования (позволяет потоковое или форматирование или что-то в этом роде)
  3. надежный (не протекать и не разбиться!)
  4. кроссплатформенный (по крайней мере, Windows, MacOSX, Linux / Ubuntu)

Какую библиотеку журналов вы бы порекомендовали?

В настоящее время я считаю, что boost :: log является наиболее гибким (вы даже можете войти в систему удаленно!), Но у него не очень хорошее обновление производительности : оно предназначено для высокой производительности, но еще не выпущено. Часто упоминают о Pantheios, но у меня нет точек сравнения производительности и использования. Я давно использовал свою собственную библиотеку, но я знаю, что она не справляется с многопоточностью, поэтому это большая проблема, даже если она достаточно быстра. Google Log кажется интересным, мне просто нужно протестировать его, но если вы уже сравнили эти библиотеки и многое другое, ваш совет может быть полезным.

Игры часто требуют высокой производительности, но сложны в отладке, поэтому было бы хорошо знать библиотеки журналов, которые в нашем конкретном случае имеют явные преимущества.


3
Одно из важных требований, о которых вы не упомянули, - это то, для чего вы собираетесь использовать журналы. Требования к ведению журнала, скажем, сообщений отладки, метрик для дизайнеров, состояния символов для поддержки клиентов и транзакций по кредитным картам, различны. Как правило, вы компенсируете производительность, простоту использования для программистов, простоту / скорость автономного анализа и долговечность в зависимости от ситуации.

Это верно, но я предполагал, что «полное» решение для ведения журналов позволит пользователям настраивать различные типы журналов, как вы описываете. Если вы нашли эту точность важной в вопросе, пожалуйста, будьте моим гостем и добавьте ее к вопросу.
Klaim

Ответы:


8

ведение журнала с использованием сокета (может быть достаточно любой оболочки) + веб-браузер websocket => наиболее универсальный, ненавязчивый инструмент ведения журналов, который отработает часы отладки и позволит избежать неприятных ощущений .

  • асинхронный (скорость, поскольку она откладывает всю работу в браузере)
  • отформатированный (цвет, размер и т. д.)
  • надежный (розетки ...)
  • кроссплатформенный (браузер)

Теперь бонус:

  • динамическая фильтрация очень легко сделать (используя регулярное выражение javascript, если это необходимо)
  • с журналом журнала, памятью и сравнением (спецификация HTML5 в базе данных "in-browser")
  • Простой способ создать какой-либо график из любых данных (используя SVG, Canvas или что-либо еще), таких как память , фрагментация памяти и т. Д.
  • простой способ создать некоторый 2D-график из любых данных ( подразделение дерева kd « потенциальное поле» или даже просто изменение значения переменной и т. д.)
  • позволяет удаленную регистрацию (используя браузер на другом компьютере)
  • используя html5 в хранилище браузера, вы можете хранить параметры сеанса журнала (текущие фильтры журнала и т. д. и даже примечания к каждому)
  • очень легко создать отчет об ошибке или ссылку на тик билеты только одним кликом
  • возможность перемотки логов легко с графическим интерфейсом

и многое другое вне логирования:

  • позволяет информацию профилировщика (графики ...)
  • может даже служить в качестве консоли (отправить команду из браузера) или даже с быстрым графическим интерфейсом, используя HTML или даже флэш-интерфейс
  • Различия в изображениях в браузере (отправка изображения с использованием сокета и сравнение в браузере с использованием возможностей изображения на холсте)
  • и т.д...

(почти все вышеперечисленное можно сделать с помощью флеш-сокетов, сохранив возможности базы данных)

Теперь я знаю, что кажется, это немного долго настраивать. Но это действительно выигрыш времени в длинном проекте, в сложной ситуации отладки (например, в играх). Это самая мощная вещь, которую я использовал со времен отладчиков ...

Примечание 1: единственный недостаток => двойная проверка побочного эффекта при отладке игрового сетевого кода (влияние на размер буфера сокета, задержку, пропускную способность и т. Д.)

Примечание 2: некоторые веб-сокеты отключены по умолчанию из-за соображений безопасности, проверьте: настройте параметры, чтобы убедиться, что они включены.


1
Поправьте меня, если я ошибаюсь, но это только говорит о том, куда направить вывод журнала, нет? Реальная библиотека журналов также позволила бы фильтровать во время компиляции (что крайне важно, если производительность является проблемой), форматировать и предоставлять простой в использовании синтаксис для создания сообщений журнала.
ВОО

@sbi Это глобальная функция включения или выключения на стороне приложения. «Браузер журнала клиента» выполняет фильтрацию, синтаксис, но он всегда получает весь журнал. Это радикально, но основано на опыте, что во время разработки вы всегда должны регистрировать все, чтобы вы могли легко поймать / воспроизвести любые ошибки, с которыми вы столкнулись. Если вам нужно оптимизировать, это снова браузерная сторона: используя сокет, вы не обязаны регистрировать, используя строку, вы можете напрямую записывать двоичные данные (Id + float), которые выделены жирным шрифтом быстрее, чем любая другая строка на основе журнала lib ... ( соответствующий идентификатор для строки браузера ...)
Tuan Kuranes

1
Хотя я вижу, что это очень практично, на самом деле это всего лишь бэкэнд логгера (который временный журнал называет «приемником логов», IIRC). Производительность является одним из перечисленных требований. Я обнаружил, что мне нужно добавить операторы log в кусок кода при его отладке, но как только он будет запущен и запущен, этот фрагмент кода будет слишком разговорчивым и затопит все, над чем я работаю, в его шуме, а также будет стоить слишком много производительности Так что я хочу иметь возможность тонизировать уровень записи на целых кусках кода с изменением нескольких строк кода. Это то, что средний уровень log lib делает для вас.
ВОО

@sbi: может потребоваться тесты, но есть вероятность, что лучшая библиотека журналов, даже на самом низком уровне, все равно будет стоить вам дороже, чем двоичный регистратор, который регистрирует все. Нет ни одного потраченного впустую цикла процессора "двоичный код" ... Так что это действительно больше возможностей и больше производительности.
Туан Куранес

Прежде чем мы решили использовать Templog, мы провели несколько тестов. Если ведение журнала отключено для серьезности, источника или еще чего-то определенного сообщения журнала, и если компилятор может обнаружить, что при оценке параметров нет никаких побочных эффектов, то VC действительно способен оптимизировать полномасштабный записать заявление в ничто. И когда дело доходит до скорости, вы не будете бить код, который не должен быть выполнен в первую очередь.
ВОО

8

Когда дело доходит до производительности, я обнаружил, что templog практически непобедим. Он использует шаблоны выражений для того, чтобы отложить оценку операторов регистрации, пока не будет установлено, что информация будет зарегистрирована вообще. Поскольку вы также можете частично отключить ведение журнала (в зависимости от серьезности, источника и целевой аудитории сообщения журнала), некоторые из этих операторов ведения журнала могут быть удалены компилятором до нуля кода для сборок выпуска. (Я действительно видел, что это случилось с ВК.)

В последнее время с библиотекой почти ничего не было сделано, и другие в SO обнаружили, что в некоторых случаях стволу не хватает, но в компании, в которой я работал, мы нашли парня довольно отзывчивым, а один из моих тогдашних коровников даже получил доступ к коммиту и добавил к нему некоторый код, так что вы можете найти его достойным внимания.

Чтобы перечислить ваши требования:

производительность

Лучшее, что я нашел. Особенно его способность исключать сообщения журнала во время компиляции и полностью исключать их из компилятора была очень привлекательной.

простота использования (позволяет потоковое или форматирование или что-то в этом роде)

Есть классические ужасные сообщения об ошибках компилятора шаблонов-мета, когда вы делаете что-то не так, но когда дело доходит до простоты использования, это

TEMPLOG_LOG(my_logger,sev_error,aud_support) << "logged in as " << user_name;

трудно победить.
Однако вам, возможно, придется создать свои собственные приемники журналов (вот куда идут сообщения журналов), так как несколько предварительно упакованных (stderr, file, Windows logging и т. Д.) Не так уж и сложны. Из-за того, что производительность является основной целью, внутренняя сущность всего этого несколько сложна (например, средства форматирования сообщений журнала весьма запутаны с приемниками журналов), но мы справились с этим (я помню, как проходили через него в отладчике, помогающем с этим) и однажды Я понял, что не так уж сложно написать свои собственные средства форматирования сообщений или приемники журналов.

надежный (не протекать и не разбиться!)

Мы использовали его, не найдя таких серьезных проблем. Там практически нет динамического распределения памяти, поэтому трудно даже представить, что он что-то делает не так. Конечно, мы проводим только реальные испытания в одном продукте.

кроссплатформенный (по крайней мере, Windows, MacOSX, Linux / Ubuntu)

Когда мы использовали его, мы использовали его в Win32, OSX и нескольких различных дистрибутивах Linux, в том числе в Ubuntu.

Что касается многопоточности: мы не использовали это, но из того, что я помню об архитектуре lib, кажется, вам нужно будет обрабатывать это только в приемниках журналов. ICBWT.


Спасибо, я этого не знал. Это похоже на упрощенную (и производительную) версию boost :: log, по крайней мере, в оригинальной идее.
Klaim

@Klaim: Я не думаю, что boost мог что-то предложить, когда я в последний раз изучал библиотеки журналов C ++, поэтому я не знаю о boost :: log.
ВОО

1
@Joe: вы понимаете термин "шаблоны выражений" ??
ВОО

1
Я думал, что сделал, но теперь я скачал и начал читать исходный код временного журнала, и, похоже, C ++ снова перехитрил меня.

1
@sbi: Часть моей путаницы заключалась в том, что ваше заявление «пропущено сразу через несколько слоев» - на английском языке сразу может означать либо сразу, либо вместе , что в данном случае является противоположностью. Я прочитал это как первое, а вы (теперь, очевидно, для меня) имели в виду второе. Спасибо, что нашли время, чтобы объяснить это.


0

Вас может заинтересовать набор инструментов Baical :

  • Библиотека с открытым исходным кодом и кроссплатформенная (Win, Linux, x86 / x64) для журналов, трасс и телеметрии - P7
  • Невероятно быстрый (разработан для встроенных устройств) - 3 миллиона журналов в секунду в сеть, 5 миллионов в файл на современном процессоре. Я не знаю никакой другой библиотеки для регистрации, которая обеспечивает такую ​​скорость и такую ​​подробную информацию для каждого сообщения журнала.
  • Поток безопасно
  • Каждое сообщение трассировки содержит:
    • текстовое сообщение
    • уровень
    • точное время (100 нс)
    • исходный файл, имя функции и строка
    • идентификатор модуля и имя модуля
    • ID потока и имя потока
    • индекс ядра процессора
  • Серверное приложение для получения и просмотра логов и телеметрии
  • Вы можете собирать, анализировать, искать, фильтровать журналы из нескольких источников в режиме реального времени

По состоянию на 06/2017% s в форматировании строки пока не поддерживается.
Romeno
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.