Наверху связанный с OutputDebugString в сборке конечных версий
Один из способов - перетасовать диапазон и взять столько предметов, сколько вы хотите:
val randomList = (0..99).shuffled().take(4)
Это не так эффективно, если диапазон большой и вам нужен только один несколько чисел.
В этом случае лучше использовать Set , например:
val s: MutableSet = mutableSetOf()
while (s.size < 4) { s.add((0..99).random()) }
val randomList = s.toList()
7 ответов
Измерено - 10 миллионов вызовов занимают около 50 секунд. Я думаю, что это приводит к значительным накладным расходам на неиспользуемую функциональность.
Использование макроса может помочь избавиться от этого в сборке релиза:
#ifdef _DEBUG
#define LOGMESSAGE( str ) OutputDebugString( str );
#else
#define LOGMESSAGE( str )
#endif
Не только удаляются вызовы, но также оцениваются параметры и текстовые строки полностью удаляются, и вы будете не вижу их в двоичном файле.
Я читал в статье, что OutPutDebugString внутренне делает несколько интересных вещей:
- Создает \ Открывает мьютекс и ждет бесконечно до получения мьютекса.
- Передача данных между приложением и отладчиком осуществляется через блок общей памяти размером 4 Кбайт с Mutex и двумя объектами Event, защищающими доступ к нему.
Даже если отладчик не подключен ( в режиме релиза) использование OutputDebugstring связано с использованием различных объектов ядра.
Падение производительности очень заметно, если вы напишите пример кода и протестируете его.
За последние годы я не видел проблем в десятках приложений режима выпуска на стороне сервера, которые все имеют встроенные метрики. Вы можете создать впечатление , что оно медленное, потому что большинство приложений отладчика, которые вы можете найти (DBWIN32 и др.), Довольно медленно выводят данные на экран, что создает впечатление запаздывания.
Конечно, во всех наших приложениях этот вывод по умолчанию отключен, но он полезен , чтобы иметь возможность включать его в полевых условиях, так как вы можете затем просматривать выходные данные отладки из нескольких приложений, сериализованных в что-то вроде DBWin32. Это может быть очень полезной техникой отладки ошибок, связанных с передачей приложений.
Never leave OutputDebugString() calls in a release build. Always either remove them by using #ifdef statements, or provide another switch to have them turned off.
If you leave them in, have them disabled by default and only activate them on request, because otherwise your app will make it hard to debug other apps which behave nice (i.e., only output debug data on request).
Theres DebugView to catch the output of apps, but of course that's only good if not every app chatters along for no good reason.
Почему бы не измерить это самостоятельно? Скомпилируйте следующий код, запустите его и проверьте время. Затем удалите вызов OutputDebugString, перекомпилируйте и запустите снова. Должно занять около трех минут вашего времени.
#include <windows.h>
int main() {
const int COUNT = 1000000;
int z = 0;
for ( unsigned int i = 0; i < COUNT; i++ ) {
z += i;
OutputDebugString( "foo" );
}
return z;
}
Я пишу это спустя много времени после того, как на этот вопрос был дан ответ, но в приведенных ответах отсутствует определенный аспект:
OutputDebugString может работать довольно быстро, когда никто не слушает его вывод. Однако наличие прослушивателя, работающего в фоновом режиме (будь то DbgView, DBWin32, Visual Studio и т. Д.), Может сделать его более чем в 10 раз медленнее (гораздо больше в среде MT). Причина в том, что эти слушатели перехватывают событие отчета, и их обработка события выполняется в рамках вызова OutputDebugString. Более того, если несколько потоков вызовут OutputDebugString одновременно, они будут синхронизированы. Для получения дополнительной информации см. Осторожно: DebugView (OutputDebugString) и Performance .
В качестве примечания, я думаю, что если вы не запускаете приложение реального времени, Вы не должны так беспокоиться об объекте, которому требуется 50 секунд для выполнения 10 миллионов вызовов. Если ваш журнал содержит 10 миллионов записей, потраченные впустую 50 секунд - наименьшая из ваших проблем, теперь, когда вам нужно как-то проанализировать зверя. Журнал размером 10 Кбайт звучит гораздо более разумно, и создание его займет всего 0,05 секунды согласно измерениям острого зуба.
Итак, если ваш вывод находится в разумных пределах, использование OutputDebugString не должно вам сильно повредить. Однако имейте в виду, что когда кто-то в системе начнет прослушивать этот вывод, произойдет замедление.
если ваш вывод находится в пределах разумного размера, использование OutputDebugString не должно вам сильно повредить. Однако имейте в виду, что когда кто-то в системе начнет прослушивать этот вывод, произойдет замедление. если ваш вывод находится в пределах разумного размера, использование OutputDebugString не должно вам сильно повредить. Однако имейте в виду, что когда кто-то в системе начнет прослушивать этот вывод, произойдет замедление.I Мне было интересно узнать об этой теме, поэтому я провел небольшое исследование.
Я опубликовал результаты, исходный код и файлы проекта, чтобы вы могли повторить тесты для своей установки. Охватывает запуск приложения в режиме выпуска без какого-либо мониторинга OutputDebugString, а затем с помощью Visual Studio 6, Visual Studio 2005 и Visual Studio 2010, отслеживающего OutputDebugString, чтобы увидеть, какие различия в производительности существуют для каждой версии Visual Studio.
Интересные результаты: Visual Studio 2010 обрабатывает информацию OutputDebugString до 7 раз медленнее, чем Visual Studio 6.
Полная статья здесь: Сколько стоит OutputDebugString?