Как ускорить Visual Studio?

@SergeyKagen · Регистрация: 02.04.2018

Author24 — интернет-сервис помощи студентам

имеется
AMD Ryzen 5 3600 (6 core) 3,59 GHz
16Gb ОЗУ
nVidia 1660 ti

Но даже с такими параметрами я заметил что программа в режиме Debug загружает данные в оперативную память как-то медленно. Это не тормоза, это такое ощущение что, урезание ресурсов, как будто замедление их специально. Особенно это ощущается на библиотеке dlib. Я знаю что эта библиотека может быть шустрой, но она картинку обрабатывает размером 2560 х 1449 х 24 bpp - одну минуту. Это очень много как по мне. Хотя я видел, что с этой библиотекой даже делают захват веб камеры и она шустро работает. Но тут, как дело доходит до загрузки картинки в dlib, график оперативной памяти справа медленно растёт, и потом ещё думает.
Я подумал, может в настройках Visual Studio есть какой-то параметр, который намеренно замедляет скорость работы программы? И у меня из-за этого получается такие вот тормоза? Потому что параметры машины моей не айс, но я думаю загрузить и обработать изображение с такими параметрами заняло бы не минуту это точно.

@KSergey9 · 05.12.2022, 08:31

Сообщение от SergeyKagen

Я подумал, может в настройках Visual Studio есть какой-то параметр, который намеренно замедляет скорость работы программы?

В каком-то смысле да, Debug отключает все оптимизации, а это порой существенно влияет на скорость.
С другой стороны не понятно как именно выполняется в этом случае код из указанной dlib. Вполне возможно, что именно ее работа от debug/release не зависит.

Соберите в Release и посмотрите меняется что-то или нет.

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

Сообщение от SergeyKagen

Потому что параметры машины моей не айс

Да вы, батенька, заемшись

@TheCalligrapher · 05.12.2022, 08:40

Сообщение от SergeyKagen

Но даже с такими параметрами я заметил что программа в режиме Debug загружает данные в оперативную память как-то медленно. Это не тормоза, это такое ощущение что, урезание ресурсов, как будто замедление их специально. Особенно это ощущается на библиотеке dlib.

Так а сама библиотека dlib, используемая вашим приложением в режиме Debug, тоже откомпилирована в режиме Debug?

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

Если же библиотека dlib сама по себе всегда откомпилирована в оптимизированном виде, то теоретически возможно еще некоторое замедление из-за использования отладочной кучи при запуске из под IDE, как описано здесь: https://preshing.com/20110717/... -debugger/

Лечится установкой переменной окружения _NO_DEBUG_HEAP в 1 либо глобально, либо в настройках Visual Studio только для окружения запускаемого приложения.

@SergeyKagen · 05.12.2022, 09:01 **[ТС]**

О, а вот это я и не знал. Т.е. Debug и Release отличаются по скорости? А нельзя ли как-то ускорить Debug ну всмысле выбрать скорость у Debug-a? Или этот параметр не регулируемый?

@KSergey9 · 05.12.2022, 09:04

Включите Release и спокойно отлаживайтесь. Да, возможно значения некоторых переменных не сможете посмотреть, т.к. они будут "оптимизированы" (выкинуты) оптимизатором. Да и пофик обычно.

Но для начала сравните, будет ли быстрее в релизе. А то может беда не в этом.

@TheCalligrapher · 05.12.2022, 09:09

Сообщение от SergeyKagen

Т.е. Debug и Release отличаются по скорости?

??? Debug и Release астрономически отличаются по скорости.

Сообщение от SergeyKagen

А нельзя ли как-то ускорить Debug ну всмысле выбрать скорость у Debug-a?

"Debug" и "Release" - это просто текстовые имена конфигураций проекта. Вы можете их удалить или сами еще добавить в этот список "Vasya" и "FooBar". Все в ваших руках.

Все параметры этих конфигураций свободно настраиваются в настройках проекта. Вы можете превратить Debug в Release просто аккуратно скопировав все настройки из второго в первый. Или постепенно перенося настройки из Release в Debug вы будете "ускорять" Debug и рано или поздно превратите его в Release.

Но зачем?

В можете зайти в настройки Release и там включить отладочную информацию, что даст вам возможность исполнять Release по шагам под дебаггером. Но там все будет очень неочевидно, из-за оптимизаций.

@SergeyKagen · 05.12.2022, 09:38 **[ТС]**

Хорошо, понял, спасибо, попробую в Realese перевести.

Добавлено через 24 минуты
Да, скорость обработки просто в разы отличается. Всё моментально. Теперь меня мучает вопрос, что в Debug-е тормозит так процессы?

@KSergey9 · 05.12.2022, 09:56

Например, честное копирование обьектов "как по книжке".

Например, вот в этом коде

C++    
        
    Скопировано
1
2
3
4
std:string GetStr();  // где-то реализована такая функция
 
std::string s;
s = GetStr();

в дебаге будет честно вызван конструктор string, потом внутри GetStr() будет честно сконструирована строка (её ж надо вернуть), а после сработает оператор =, а внутренняя строка в GetStr() будет уничтожена.

А в релизе оптимизатор всё это упихает так, что будет только один вызов конструктора на весь этот код - и все. И никакого = по выходу из GetStr(), т никакого уничтожения внутренней строки.
Т.е. оптимизатор как бы преобразует это все примерно в такой код:

C++    
        
    Скопировано
1
2
3
4
std:string GetStr(std::string& s);  // где-то реализована такая функция
 
std::string s;
GetStr(s);

И так для любых объектов.

ЗЫ
Какие-то детали могу тут приврать, но в целом идея именно такая.

@TheCalligrapher · 05.12.2022, 10:56

Сообщение от KSergey9

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

Нет, ничего подобного не будет. Присваивание не может быть устранено подобным образом.

Теоретически, конечно, все разрешено, если оно не влияет на наблюдаемое поведение программы, но компиляторы этим заниматься не будут для мало-мальски нетривиального присваивания. Как, например, у std::string.

@KSergey9 · 05.12.2022, 10:57

Сообщение от TheCalligrapher

Присваивание не может быть устранено подобным образом.

Проведите эксперимент. Доложите и точных результатах.

Как я говорил, то, что все точно буквально так как я написал - настаивать не стану.
Но конструкторов / деструкторов будет вызвано существенно меньшее количество, т.к. промежуточные объекты не будут создаваться вовсе.

@TheCalligrapher · 05.12.2022, 11:06

Сообщение от KSergey9

Проведите эксперимент. Доложите и точных результатах.

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

Сообщение от KSergey9

Но конструкторов / деструкторов будет вызвано существенно меньшее количество, т.к. промежуточные объекты не будут создаваться вовсе.

"Конструкторов / деструкторов"? "Конструкторы / деструкторы" - это совсем другая история, которая, кстати, во многих (в большинстве?) случаев не будет имеет отношения к заявленной вами разнице между Debug и Release, ибо язык С++ уже содержит гарантии устранения промежуточных объектов. То есть никакой разницы между Debug и Release в этом отношении не будет. (Будет или не будет - однозначно сказать нельзя, так как вы не привели определения функции.)

Но ваш пост выше не имеет никакого отношения к "конструкторам / деструкторам". Ваш пост - про устранение оператора присваивания. Оператор присваивания - это не конструктор и не деструктор. Это совсем другая тема.

@KSergey9 · 05.12.2022, 11:11

Короче будем словоблудить.
Да пожалуйста!

@TheCalligrapher · 05.12.2022, 11:22

Не по теме:

Прикольно. В форуме по языку С++ назвать обсуждение конкретных свойств и особенностей языка С++ "словоблудием"... O_o???

"Теперь я видел всё" (c) :O)

@KSergey9 · 05.12.2022, 11:27

Не по теме:

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

Добавлено через 1 минуту

Сообщение от TheCalligrapher

Но ваш пост выше не имеет никакого отношения к "конструкторам / деструкторам"

Это вы так решили.
А я говорил про количество конструирований объектов. Говорил? да, говорил.

@TheCalligrapher · 05.12.2022, 13:35

Сообщение от KSergey9

Вы пишете общие слова. Это и есть словоблудие, ибо фактами никакими не подтверждаете.

Еще раз: обязанность "подтверждать фактами" ваши заявления лежит целиком на вас.

Сообщение от KSergey9

А я говорил про количество конструирований объектов. Говорил? да, говорил.

Так о том-то и речь, что вы неправильно говорили, т.е. несли чушь. От того, что вы будете назвать присваивание "конструированием", присваивание конструированием не станет. Даже если вы будете повторять это снова и снова много много раз.

@hoggy · 05.12.2022, 16:43

Сообщение от SergeyKagen

что в Debug-е тормозит так процессы?

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

debug/release

есть такая проблема:
если в код добавить кучу различных проверок,
тогда он начнет работать медленнее.
а если не добавлять, тогда как мы узнаем об ошибках?

для решения этой проблемы изобрели debug и release.
так назывваемую "отладочную сборку",
и так называемую "релизную сборку".

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

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

таким образом достигается разумный баланс между "медленно, но надежно",
и "быстро, но без проверок"

для вставки отладочных проверок,
в с++ предусмотрен стандартный макрос assert

обрати внимание:
если стандартный дефайн препроцессора NDEBUG определен,
значит у тебя релиз, и весь макрос assert превратится в пустоту.
поэтому, проверка не войдёт в компиляцию.

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

все цивилизованные IDE,
и конфигураторы сборки учитывают стандартный дефайн препроцессора NDEBUG

поэтому, если тебя спросят на собеседовании:
чем дебаг отличается от релиза?

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

Новые блоги и статьи Все статьи Все блоги /
Управление зависимостями в Python с Poetry py-thonny 04.04.2025 Стандартный инструмент для установки пакетов в Python - pip - прекрасно справляется с базовыми сценариями: установил пакет командой pip install и используешь его. Но что произойдёт, когда разные. . .	Мониторинг с Prometheus в PHP Jason-Webb 04.04.2025 Prometheus выделяется среди других систем мониторинга своим подходом к сбору и хранению метрик. В отличие от New Relic, который использует агентный подход и отправляет данные во внешнее хранилище,. . .	Пакет Context в Golang: Управление потоками и ресурсами golander 04.04.2025 Работа с горутинами в Go часто напоминает управление непослушными детьми - они разбегаются кто куда, делают что хотят и не всегда завершаются вовремя. К счастью, в Go 1. 7 появился пакет context,. . .	Контейнеризация React приложений с Docker Reangularity 03.04.2025 Контейнеризация позволяет упаковать приложение со всеми его зависимостями в автономный контейнер, который можно запустить на любой платформе с установленным Docker. Это существенно упрощает процессы. . .	Свой попап в SwiftUI mobDevWorks 03.04.2025 SwiftUI, как декларативный фреймворк от Apple, предоставляет множество инструментов для создания пользовательских интерфейсов. В нашем распоряжении есть такие API как alerts, popovers, action sheets. . .
Антипаттерны микросервисной архитектуры ArchitectMsa 03.04.2025 Хорошо спроектированная микросервисная система может выдержать испытание временем, оставаясь гибкой, масштабируемой и устойчивой к большинству проблем. Такая архитектура обладает высоким уровнем. . .	std::mutex в C++: Советы и примеры использования bytestream 03.04.2025 std::mutex - это механизм взаимного исключения, который гарантирует, что критический участок кода выполняется только одним потоком в каждый момент времени. Это простое, но могущественное средство. . .	Не удержался от оценки концепции двигателя Стирлинга. Hrethgir 03.04.2025 Сколько не пытался - она выдавала правильные схемы, причём случайно рисовала горячие области в середине, холодные по краям, трубки с краёв в низ и магнит в соединяющей, но при этой выдавала описание. . .	Метод с двумя буферами (или double buffering) или ping-pong buffering Hrethgir 02.04.2025 Из ответов LM модели. Метод, который предполагает использование двух массивов для хранения промежуточных результатов сложения векторов, обычно применяется в сценариях, где необходимо минимизировать. . .	На любовном киберфронте Alexander-7 01.04.2025 Недавно на одном малоизвестном сайте знакомств мною заинтересовалась девушка: «Текст немного странный. Но, судя по адресу почты, иностранка», – подумал я. Поколебавшись пару суток, я ответил ей:. . .

@SergeyKagen 7 / 8 / 3 Регистрация: 02.04.2018 Сообщений: 522

	Как ускорить Visual Studio? 05.12.2022, 08:10. Показов 1351. Ответов 15 Метки нет (Все метки) имеется AMD Ryzen 5 3600 (6 core) 3,59 GHz 16Gb ОЗУ nVidia 1660 ti Но даже с такими параметрами я заметил что программа в режиме Debug загружает данные в оперативную память как-то медленно. Это не тормоза, это такое ощущение что, урезание ресурсов, как будто замедление их специально. Особенно это ощущается на библиотеке dlib. Я знаю что эта библиотека может быть шустрой, но она картинку обрабатывает размером 2560 х 1449 х 24 bpp - одну минуту. Это очень много как по мне. Хотя я видел, что с этой библиотекой даже делают захват веб камеры и она шустро работает. Но тут, как дело доходит до загрузки картинки в dlib, график оперативной памяти справа медленно растёт, и потом ещё думает. Я подумал, может в настройках Visual Studio есть какой-то параметр, который намеренно замедляет скорость работы программы? И у меня из-за этого получается такие вот тормоза? Потому что параметры машины моей не айс, но я думаю загрузить и обработать изображение с такими параметрами заняло бы не минуту это точно. 0

@KSergey9 617 / 513 / 104 Регистрация: 05.08.2022 Сообщений: 2,775
	05.12.2022, 08:31
	Сообщение от SergeyKagen Я подумал, может в настройках Visual Studio есть какой-то параметр, который намеренно замедляет скорость работы программы? В каком-то смысле да, Debug отключает все оптимизации, а это порой существенно влияет на скорость. С другой стороны не понятно как именно выполняется в этом случае код из указанной dlib. Вполне возможно, что именно ее работа от debug/release не зависит. Соберите в Release и посмотрите меняется что-то или нет. А вот то, как вы с ней работаете - большой неизученный вопрос. Может вы такие параметры задаете, что там вагон работы приходится делать. Сообщение от SergeyKagen Потому что параметры машины моей не айс Да вы, батенька, заемшись 0

@TheCalligrapher Вездепух 12873 / 6737 / 1810 Регистрация: 18.10.2014 Сообщений: 17,057
	05.12.2022, 08:40
	Сообщение от SergeyKagen Но даже с такими параметрами я заметил что программа в режиме Debug загружает данные в оперативную память как-то медленно. Это не тормоза, это такое ощущение что, урезание ресурсов, как будто замедление их специально. Особенно это ощущается на библиотеке dlib. Так а сама библиотека dlib, используемая вашим приложением в режиме Debug, тоже откомпилирована в режиме Debug? Если да, то все нормально. Режим Debug и должен быть медленнее. То есть не ясно, с чего это вдруг вы даже задаете такой вопрос. Если же библиотека dlib сама по себе всегда откомпилирована в оптимизированном виде, то теоретически возможно еще некоторое замедление из-за использования отладочной кучи при запуске из под IDE, как описано здесь: https://preshing.com/20110717/... -debugger/ Лечится установкой переменной окружения `_NO_DEBUG_HEAP` в `1` либо глобально, либо в настройках Visual Studio только для окружения запускаемого приложения. 0

@SergeyKagen 7 / 8 / 3 Регистрация: 02.04.2018 Сообщений: 522
	05.12.2022, 09:01 [ТС]
	О, а вот это я и не знал. Т.е. Debug и Release отличаются по скорости? А нельзя ли как-то ускорить Debug ну всмысле выбрать скорость у Debug-a? Или этот параметр не регулируемый? 0

@KSergey9 617 / 513 / 104 Регистрация: 05.08.2022 Сообщений: 2,775
	05.12.2022, 09:04
	Включите Release и спокойно отлаживайтесь. Да, возможно значения некоторых переменных не сможете посмотреть, т.к. они будут "оптимизированы" (выкинуты) оптимизатором. Да и пофик обычно. Но для начала сравните, будет ли быстрее в релизе. А то может беда не в этом. 0

@TheCalligrapher Вездепух 12873 / 6737 / 1810 Регистрация: 18.10.2014 Сообщений: 17,057
	05.12.2022, 09:09
	Сообщение от SergeyKagen Т.е. Debug и Release отличаются по скорости? ??? Debug и Release астрономически отличаются по скорости. Сообщение от SergeyKagen А нельзя ли как-то ускорить Debug ну всмысле выбрать скорость у Debug-a? "Debug" и "Release" - это просто текстовые имена конфигураций проекта. Вы можете их удалить или сами еще добавить в этот список "Vasya" и "FooBar". Все в ваших руках. Все параметры этих конфигураций свободно настраиваются в настройках проекта. Вы можете превратить Debug в Release просто аккуратно скопировав все настройки из второго в первый. Или постепенно перенося настройки из Release в Debug вы будете "ускорять" Debug и рано или поздно превратите его в Release. Но зачем? В можете зайти в настройки Release и там включить отладочную информацию, что даст вам возможность исполнять Release по шагам под дебаггером. Но там все будет очень неочевидно, из-за оптимизаций. 1

@SergeyKagen 7 / 8 / 3 Регистрация: 02.04.2018 Сообщений: 522
	05.12.2022, 09:38 [ТС]
	Хорошо, понял, спасибо, попробую в Realese перевести. Добавлено через 24 минуты Да, скорость обработки просто в разы отличается. Всё моментально. Теперь меня мучает вопрос, что в Debug-е тормозит так процессы? 0

@TheCalligrapher Вездепух 12873 / 6737 / 1810 Регистрация: 18.10.2014 Сообщений: 17,057
	05.12.2022, 10:56
	Сообщение от KSergey9 А в релизе оптимизатор всё это упихает так, что будет только один вызов конструктора на весь этот код - и все. И никакого = по выходу из GetStr(), т никакого уничтожения внутренней строки. Нет, ничего подобного не будет. Присваивание не может быть устранено подобным образом. Теоретически, конечно, все разрешено, если оно не влияет на наблюдаемое поведение программы, но компиляторы этим заниматься не будут для мало-мальски нетривиального присваивания. Как, например, у `std::string`. 0

@KSergey9 617 / 513 / 104 Регистрация: 05.08.2022 Сообщений: 2,775
	05.12.2022, 10:57
	Сообщение от TheCalligrapher Присваивание не может быть устранено подобным образом. Проведите эксперимент. Доложите и точных результатах. Как я говорил, то, что все точно буквально так как я написал - настаивать не стану. Но конструкторов / деструкторов будет вызвано существенно меньшее количество, т.к. промежуточные объекты не будут создаваться вовсе. 0

@TheCalligrapher Вездепух 12873 / 6737 / 1810 Регистрация: 18.10.2014 Сообщений: 17,057
	05.12.2022, 11:06
	Сообщение от KSergey9 Проведите эксперимент. Доложите и точных результатах. Нет. Я указал на очевидную ошибку в вашем посте. Если вы продолжаете настаивать на корректности того, что вы заявили, то вперед: эксперименты и доклады. Сообщение от KSergey9 Но конструкторов / деструкторов будет вызвано существенно меньшее количество, т.к. промежуточные объекты не будут создаваться вовсе. "Конструкторов / деструкторов"? "Конструкторы / деструкторы" - это совсем другая история, которая, кстати, во многих (в большинстве?) случаев не будет имеет отношения к заявленной вами разнице между Debug и Release, ибо язык С++ уже содержит гарантии устранения промежуточных объектов. То есть никакой разницы между Debug и Release в этом отношении не будет. (Будет или не будет - однозначно сказать нельзя, так как вы не привели определения функции.) Но ваш пост выше не имеет никакого отношения к "конструкторам / деструкторам". Ваш пост - про устранение оператора присваивания. Оператор присваивания - это не конструктор и не деструктор. Это совсем другая тема. 0

@KSergey9 617 / 513 / 104 Регистрация: 05.08.2022 Сообщений: 2,775
	05.12.2022, 11:11
	Короче будем словоблудить. Да пожалуйста! 0

@TheCalligrapher
	05.12.2022, 11:22
	Не по теме: Прикольно. В форуме по языку С++ назвать обсуждение конкретных свойств и особенностей языка С++ "словоблудием"... O_o??? "Теперь я видел всё" (c) :O) 0

@KSergey9 617 / 513 / 104 Регистрация: 05.08.2022 Сообщений: 2,775
	05.12.2022, 11:27
	Не по теме: Вы пишете общие слова. Это и есть словоблудие, ибо фактами никакими не подтверждаете. Достаточно провести эксперимент, поделиться результатами и сказать как будет точно на самом деле. Это уже будет предметный разговор. Добавлено через 1 минуту Сообщение от TheCalligrapher Но ваш пост выше не имеет никакого отношения к "конструкторам / деструкторам" Это вы так решили. А я говорил про количество конструирований объектов. Говорил? да, говорил. 0

@TheCalligrapher Вездепух 12873 / 6737 / 1810 Регистрация: 18.10.2014 Сообщений: 17,057
	05.12.2022, 13:35
	Сообщение от KSergey9 Вы пишете общие слова. Это и есть словоблудие, ибо фактами никакими не подтверждаете. Еще раз: обязанность "подтверждать фактами" ваши заявления лежит целиком на вас. Сообщение от KSergey9 А я говорил про количество конструирований объектов. Говорил? да, говорил. Так о том-то и речь, что вы неправильно говорили, т.е. несли чушь. От того, что вы будете назвать присваивание "конструированием", присваивание конструированием не станет. Даже если вы будете повторять это снова и снова много много раз. 0

@hoggy 8973 / 4319 / 960 Регистрация: 15.11.2014 Сообщений: 9,760
	05.12.2022, 16:43
	Сообщение от SergeyKagen что в Debug-е тормозит так процессы? отладочная конфигурация включает в компиляцию код всевозможных проверок входных аргументов и выходных значений. debug/release есть такая проблема: если в код добавить кучу различных проверок, тогда он начнет работать медленнее. а если не добавлять, тогда как мы узнаем об ошибках? для решения этой проблемы изобрели debug и release. так назывваемую "отладочную сборку", и так называемую "релизную сборку". идея заключается в том, что бы на этапе разработки использовать отладочную версию, которая за счет множества проверок способна выявлять программные ошибки. да, она может работать значительно медленнее, но зато позволяет находить, и удобно отлаживать баги. а после того, как продукт уже тщательно протестирован и отлажен, выполняется сборка релизной версии, которая уже не содержит отладочного кода, и поэтому работает шустрее. таким образом достигается разумный баланс между "медленно, но надежно", и "быстро, но без проверок" для вставки отладочных проверок, в с++ предусмотрен стандартный макрос assert обрати внимание: если стандартный дефайн препроцессора NDEBUG определен, значит у тебя релиз, и весь макрос assert превратится в пустоту. поэтому, проверка не войдёт в компиляцию. а если не определен, значит - дебаг. соответственно, выражение под макросом войдет в компиляцию. все цивилизованные IDE, и конфигураторы сборки учитывают стандартный дефайн препроцессора NDEBUG поэтому, если тебя спросят на собеседовании: чем дебаг отличается от релиза? ты уже знаешь что ответить: в релизе определен дефайн NDEBUG, а в дебаге - нет. и поэтому в дебаге активирован отладочный код. 0