"Отладочные логи и вызовы профилировщика в код вставляют только трусы, неудачники и /забыл слово для тех, кто плохо работает из-за своей тупости/, которые не могут программу написать правильно и эффективно сразу".
Кстати, для дров они сделали для WMI tracing специальную приблуду, которая при компиляции отладочные текстовые строки заменяет на некие ID, и в результате в бинарнике текста нет, и performance overhead значительно меньше - а все это ради того, чтобы дрова можно было релизить вместе с отладочной инфой, и если вдруг глюк, то чтобы кастомер мог прислать лог (естественно бинарный), а ты его мог распарсить. Это очень правильный подход. Я вот думаю, не сделать ли в своем проекте так же. Пока что у меня по кнопке "submit error report" на сервер тупо заливается последние 50 метров текстового лога, но это не очень эффективно :)
Хм. Интересная идея. Правда у меня кроме статических строк там еще куча переменных параметров логгится, а вот для тупого лога всех вызовов в стиле "время начала, ID вызова, время завершения" такое бы очень хорошо подошло.
А оно параметры тоже пихает. Оно парсит строку в формате printf, и соответственно генерит код (не знаю, как - макрос там или вызов чего-нибудь), который параметры тоже сохраняет. Но при этом время на генерацию собственно строки в рантайме не тратится.
помню написал интерпретатор, на нем систему, а дебаггер писать было лень, всё отлаживал в уме и при помощи просмотра консольных сообщений и ничего так справился.. можно написать сразу конечно то что работает, но для этого надо время (как Дийкстра к примеру писал о компании где в годовом проекте начиналось программирование после 9-10 месяцев обдумывания), но кто же у нас даст время, у нас требуют за год догнать и перегнать конкурента который 10 лет упсешно на рынке работает
Простой текстовый лог намного удобней. Хотя бы потому, что не требуется сторонних средств для его расшифровки. Если волнует размер -- можно агрессивно пожать, например в lzma. Не думаю, что overhead на логинг может быть существенным. Описанный подход может быть интересен, только для сокрытия информации, что бы людишки ни в коем случае не догадались как эта ентерпрайзная поделка работает.
Если сервер хорошо нагружен, там лишний обмен с диском и расход проца на lzma однозначно ни к чему. Да и сокрытие информации тоже идея хорошая, каким-нибудь конкурентам или местным криворуким админам вовсе ни к чему знать подробности работы софта.
Если вы читали мой коммент внимательно, вы бы заметили, что там написано "для дров". Если в обработчике прерывания будет происходить printf и lzma, вы сильно удивитесь, что это у вас Core2 Duo окошки перерисовывает со скоростью 386.
Простой текстовый лог, конечно, удобней, но не всегда.
Лог, в нормальной ситуации, вряд ли привысит 1Mb/час. Даже на загруженном сервере это не создаст большой нагрузки. А жать можно только при пересылке или logrotate. И, да, я всегда догадывался, что проприетарщики считают всех вокруг тупыми.
Вот про это я и написал "логи пишут только трусы и неудачники". Потому что настоящие гуру и ковбои от программирования сразу пишут правильно, а причину проблем у клиента узнают с помощью телепатической силы.
1 мегабайт в час? А 100 кб в секунду не хотите ли при отладке, причем отладка именно производительности, т.е. логгинг должен отъедать как можно меньше, чтобы не повлиять на отлаживаемый аспект системы.
Я полагаю, вы не производите отладку на стороне клиета? Или производите? "Отладка производительности" -- это профайлинг? Для этого существуют более эффективные средства, чем логгинг.
При управлении железкой 10 мб лога в минуту - сплошь и рядом. Бывают и метры в секунду. Потому что когда в цеху встает конвейер, а на вопрос "что случилось" разработчики недоуменно разводят руками и говорят "ну знаете, нам надо посмотреть отладчиком", их немедленно увольняют.
Не самая, но как-то отлаживать нужно. Breakpoint-то туда можно поставить только один раз по понятным причинам, а просто DbgPrint таки вносит коррективы :) Конечно, есть и плугин к kd, и если сказать /debugport=1394, то даже и с DbgPrint можно жить, но тем не менее.
Для слива и анализа бинарных логов они там дают тулзу. Все это довольно надежно работает, как ни странно.
Разумеется, оставлять даже бинарный лог в обработчике прерывания в релизе не сильно кошерно. Хотя некоторые оставляют, а некоторые даже это оговаривают в спецификации, что WMI tracing должен быть в релизе. Там действительно performance overhead очень маленький.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
Описанный подход может быть интересен, только для сокрытия информации, что бы людишки ни в коем случае не догадались как эта ентерпрайзная поделка работает.
no subject
no subject
Простой текстовый лог, конечно, удобней, но не всегда.
no subject
no subject
И, да, я всегда догадывался, что проприетарщики считают всех вокруг тупыми.
no subject
Потому что настоящие гуру и ковбои от программирования сразу пишут правильно, а причину проблем у клиента узнают с помощью телепатической силы.
no subject
А 100 кб в секунду не хотите ли при отладке, причем отладка именно производительности, т.е. логгинг должен отъедать как можно меньше, чтобы не повлиять на отлаживаемый аспект системы.
no subject
no subject
"Отладка производительности" -- это профайлинг? Для этого существуют более эффективные средства, чем логгинг.
no subject
no subject
no subject
no subject
Для слива и анализа бинарных логов они там дают тулзу. Все это довольно надежно работает, как ни странно.
Разумеется, оставлять даже бинарный лог в обработчике прерывания в релизе не сильно кошерно. Хотя некоторые оставляют, а некоторые даже это оговаривают в спецификации, что WMI tracing должен быть в релизе. Там действительно performance overhead очень маленький.