"Отладочные логи и вызовы профилировщика в код вставляют только трусы, неудачники и /забыл слово для тех, кто плохо работает из-за своей тупости/, которые не могут программу написать правильно и эффективно сразу".
Кстати, для дров они сделали для WMI tracing специальную приблуду, которая при компиляции отладочные текстовые строки заменяет на некие ID, и в результате в бинарнике текста нет, и performance overhead значительно меньше - а все это ради того, чтобы дрова можно было релизить вместе с отладочной инфой, и если вдруг глюк, то чтобы кастомер мог прислать лог (естественно бинарный), а ты его мог распарсить. Это очень правильный подход. Я вот думаю, не сделать ли в своем проекте так же. Пока что у меня по кнопке "submit error report" на сервер тупо заливается последние 50 метров текстового лога, но это не очень эффективно :)
Хм. Интересная идея. Правда у меня кроме статических строк там еще куча переменных параметров логгится, а вот для тупого лога всех вызовов в стиле "время начала, ID вызова, время завершения" такое бы очень хорошо подошло.
А оно параметры тоже пихает. Оно парсит строку в формате printf, и соответственно генерит код (не знаю, как - макрос там или вызов чего-нибудь), который параметры тоже сохраняет. Но при этом время на генерацию собственно строки в рантайме не тратится.
Простой текстовый лог намного удобней. Хотя бы потому, что не требуется сторонних средств для его расшифровки. Если волнует размер -- можно агрессивно пожать, например в lzma. Не думаю, что overhead на логинг может быть существенным. Описанный подход может быть интересен, только для сокрытия информации, что бы людишки ни в коем случае не догадались как эта ентерпрайзная поделка работает.
Если сервер хорошо нагружен, там лишний обмен с диском и расход проца на lzma однозначно ни к чему. Да и сокрытие информации тоже идея хорошая, каким-нибудь конкурентам или местным криворуким админам вовсе ни к чему знать подробности работы софта.
Лог, в нормальной ситуации, вряд ли привысит 1Mb/час. Даже на загруженном сервере это не создаст большой нагрузки. А жать можно только при пересылке или logrotate. И, да, я всегда догадывался, что проприетарщики считают всех вокруг тупыми.
1 мегабайт в час? А 100 кб в секунду не хотите ли при отладке, причем отладка именно производительности, т.е. логгинг должен отъедать как можно меньше, чтобы не повлиять на отлаживаемый аспект системы.
Я полагаю, вы не производите отладку на стороне клиета? Или производите? "Отладка производительности" -- это профайлинг? Для этого существуют более эффективные средства, чем логгинг.
При управлении железкой 10 мб лога в минуту - сплошь и рядом. Бывают и метры в секунду. Потому что когда в цеху встает конвейер, а на вопрос "что случилось" разработчики недоуменно разводят руками и говорят "ну знаете, нам надо посмотреть отладчиком", их немедленно увольняют.
Если вы читали мой коммент внимательно, вы бы заметили, что там написано "для дров". Если в обработчике прерывания будет происходить printf и lzma, вы сильно удивитесь, что это у вас Core2 Duo окошки перерисовывает со скоростью 386.
Простой текстовый лог, конечно, удобней, но не всегда.
Вот про это я и написал "логи пишут только трусы и неудачники". Потому что настоящие гуру и ковбои от программирования сразу пишут правильно, а причину проблем у клиента узнают с помощью телепатической силы.
Не самая, но как-то отлаживать нужно. Breakpoint-то туда можно поставить только один раз по понятным причинам, а просто DbgPrint таки вносит коррективы :) Конечно, есть и плугин к kd, и если сказать /debugport=1394, то даже и с DbgPrint можно жить, но тем не менее.
Для слива и анализа бинарных логов они там дают тулзу. Все это довольно надежно работает, как ни странно.
Разумеется, оставлять даже бинарный лог в обработчике прерывания в релизе не сильно кошерно. Хотя некоторые оставляют, а некоторые даже это оговаривают в спецификации, что WMI tracing должен быть в релизе. Там действительно performance overhead очень маленький.
помню написал интерпретатор, на нем систему, а дебаггер писать было лень, всё отлаживал в уме и при помощи просмотра консольных сообщений и ничего так справился.. можно написать сразу конечно то что работает, но для этого надо время (как Дийкстра к примеру писал о компании где в годовом проекте начиналось программирование после 9-10 месяцев обдумывания), но кто же у нас даст время, у нас требуют за год догнать и перегнать конкурента который 10 лет упсешно на рынке работает
![[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
А 100 кб в секунду не хотите ли при отладке, причем отладка именно производительности, т.е. логгинг должен отъедать как можно меньше, чтобы не повлиять на отлаживаемый аспект системы.
no subject
"Отладка производительности" -- это профайлинг? Для этого существуют более эффективные средства, чем логгинг.
no subject
no subject
Простой текстовый лог, конечно, удобней, но не всегда.
no subject
no subject
Потому что настоящие гуру и ковбои от программирования сразу пишут правильно, а причину проблем у клиента узнают с помощью телепатической силы.
no subject
no subject
no subject
no subject
Для слива и анализа бинарных логов они там дают тулзу. Все это довольно надежно работает, как ни странно.
Разумеется, оставлять даже бинарный лог в обработчике прерывания в релизе не сильно кошерно. Хотя некоторые оставляют, а некоторые даже это оговаривают в спецификации, что WMI tracing должен быть в релизе. Там действительно performance overhead очень маленький.
no subject
no subject
no subject