Какова производительность счетчиков производительности

накладные расходы на настройку счетчиков производительности обычно недостаточно высоки, чтобы беспокоиться (настройка области общей памяти и некоторых объектов .NET, а также накладные расходы среды CLR, потому что среда CLR фактически выполняет управление за вас). Здесь я имею в виду такие классы, как PerformanceCounter.

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

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

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

наконец, обращение к опыту: счетчики производительности настолько легкие, что они используются везде в Windows, от ядра до драйверов для пользовательских приложений. Microsoft полагается на них внутренне.

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

Я много их тестировал.

на старой процессорной машине compaq 1Ghz 1 я смог создать около 10 000 счетчиков и контролировать их удаленно для использования процессора 20%. Это не пользовательские счетчики, просто проверка процессора или что-то еще.

в основном, вы можете контролировать все счетчики на любой приличной новой машине с очень небольшим воздействием.

создание экземпляра объекта может занять много времени, от нескольких секунд до нескольких минут. Я предлагаю вы многопоточный это для всех счетчиков вы собираете в противном случае ваше приложение будет сидеть там навсегда создания этих объектов. Не уверен, что MS делает после его создания, что занимает так много времени, но вы можете сделать это для 1000 счетчиков с 1000 потоков в то же время вы можете сделать это для 1 счетчика и 1 потока.

счетчик производительности - это всего лишь указатель на 4/8 байта в общей памяти (aka memory mapped file), поэтому их стоимость очень похожа на стоимость доступа к int/long variabile.

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

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

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