Могу ли я получить ощутимые улучшения скорости, заменив Console.WriteLine структурой журналирования?

Question

В настоящее время наше победное приложение на C #, .Net 3.5 делает совсем немного Console.WriteLine(), чтобы хранить «мягкие» журналы (не сохраняются в файлах), что не совсем полезно и, вероятно, является узким местом в производительности, особеннотак как его цель - выполнить кучу вычислений как можно быстрее.

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

• оптимизировано для скорости
• , настраивается во время выполнения, то есть turnonandoffable

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

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

Я бы также подумал, что пропуск консоли и запись непосредственно в файл журнала будут быстрее (без очистки буфера и т. Д.), А такжесохранено для обзора / аудита / потомков - , поэтому в целом лучший выбор.

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

Answer 1

Я не решаюсь ответить, так как вы сами дали мои ответы, но мне не хватает репутации :) ...

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

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

Также есть возможность использовать, например. OutputDebugString и утилита просмотра (извините, опять же, без имени), если вы хотите просматривать свой журнал во время выполнения.

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

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

Так что я думаю, что у вас все в порядке, и я бы посоветовал переключиться на какой-то фреймворк как можно скорее:)

Всего одинпримечание:

без очистки буфера и т. д.

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

Answer 2

Я просто добавлю краткий пример, поскольку у нас была очень похожая проблема, и эта информация может представлять интерес.

В нашем приложении мы активно используем Log4Net.Профилировав приложение, мы поняли, что методы ILog.Log занимают слишком много времени.По сути, каждый вызов Logging был блокирующим вызовом, который записывал одну строку в текстовый файл.Простое изменение конфигурации, замена RollingFileAppender на пользовательский BufferedFileAppender значительно повысило производительность в нашем приложении.Невероятно, но некоторые операции, которые включали интенсивное ведение журнала и ранее занимали несколько секунд, были сокращены до доли секунды после выполнения этого переключения.

BufferedFileAppender, по сути, объединяет несколько сообщений журнала одновременно, ставя в очередь сообщения журнала и выполняя меньшее количество операций записи в файл.Это гарантирует, что ILog.Log действует как асинхронный вызов (с точки зрения производительности), но также обеспечивает детерминированную упорядоченную обработку сообщений журнала.

Я бы предположил, что в вашем случае Console.WriteLine блокирует - что вам идеальнонеобходимо выполнить пакетные операции и записать 100x строк за раз (или, скажем, каждые 100 мсек писать все буферизованные строки).Простой класс-оболочка вокруг Console.WriteLine может быть написан для достижения этой цели.

Answer 3

В принципе, я согласен с @Martin, но подумайте немного. Сколько сообщений в секунду регистрируется?

Если он исчисляется сотнями или более, то избавление от записи на консоль может сэкономить значительную долю времени.

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