@Kamerton

Доброго дня форумчанам

Собственно, проблема - студия стала страшно тормозить. Каждый шаг отладки занимает 5-10 секунд. Подозреваю, что что-то лишнее надо бы отключить, но не подозреваю где...

О машине:
Проц - AMD Phenom II X3 720 2,8GHz
Оперативка - 6 Gb
ОС - Windows 7 Professional SP1

VisualStudio 2012 Ultimate.

Отлаживаемый Solution состоит из 5 проектов общим весом 32Мб (включая сторонние библы общим весом ~5 мб)
Плагинов/дополнений нет, пакетов через NuGet не ставил.

Судя по диспетчеру, каждый шаг отладки съедает примерно по 40% цп (с общей загрузкой цп не выше 60). Оперативка почти не скачет...

Посмотрел в инете - не помогло...

Пока не пробовал только переустанавливать VS... Надеюсь, что до этого не дойдёт.

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

0

@Streletz

А, на каком языке написан проект? C++, C#, VB.NET? От этого тоже многое зависит.

0

@Kamerton

C#

П.С.
Думал, что уже всё учёл, ан нет жеж...

0

@Streletz

Странно, обычно .NET компилируются и отлаживаются без особых "тормозов" (в отличие от C++).
А, что пишет сама студия? Возможно в проекте есть что-то, что на каждом шаге вызывает дополнительные действия.

0

@Kamerton

А где читать? Просто я тут один такой, "программист", в конторе, так что спросить больше не у кого или посмотреть, как это должно быть

Также, у меня сложная, на мой взгляд, иерархическая структура возвращается к тому месту отладки (~1к моих объектов вложенных друг в друга). Может этого уже достаточно? Просто странно, что тогда не грузится весь ресурс проца/оперативки, если это такие нагрузки серьёзные для студии, на мой взгляд... Или может часто встречающийся [DebugDisplay] с проверками так способствует, не пойму...

0

@Streletz

Есть интернет.
Справочник по пользовательскому отладочному интерфейсу - MSDN.
Отладка приложений в Visual Studio 2010 - инструкция в 3х страницах. Отладка рассматривается на примере версии 2010, но, тем не менее, информация актуальная.
Не совсем понял, что Вы имеете в виду. Это глубина наследования 1000 или особенности композиции?

1

@Kamerton

Ой, да. Это больше композиция, глубина не больше 10. Другими словами, есть ок.20 экземпляров класса, в каждом из которых еще по 5 разных типов, в каждом из которых ещё по 5 типов и т.п. Может с 1000 я и перегнул, но думаю уж 500-то будет... Возвращает List с общим количеством ~500+ экземпляров различных типов, завязанных между собой Не знаю, как ещё объяснить...

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

0

@Streletz

Если не больше 10, то глубина более чем умеренная.
Однако даже обработка композиции такого количества взаимосвязанных объектов (да ещё многократная) вполне может требовать значительных затрат.
Попробуйте оптимизировать архитектуру.
Для получения более чёткой картины можно протестировать программу с помощью профилировщика.

1

@Kamerton

Ох, спасибо большое за новый термин Нашёл интересные статьи, буду смотреть Судя по всему, подвешивают во многом ошибки (хотя не понятно, почему также имеются тормоза при переходе к скобкам и возвратах значений... по идее там никакой же особой работы не совершается), так что посмотрим на быстродействие, как исправлю логику...

0

@Streletz

Конечно, это только краткий отчёт профилировщика (там можно посмотреть и поподробнее покликав на ссылки рядом со словами "Связанные представления"). Полагаю, что профилировщик был использован пока только в одном режиме. Выполняя тестирование с использованием нескольких можно получить более полное представление о ситуации.
Однако, даже по тем данным, что он выдал в этом кратком отчёте видно, что очень много времени потребляет работа с компасом...

1

@Kamerton

Хм... Спасибо Т.е. [clr.dll] - это всё обращения к COM-объектам Компаса? Занятно... Я уж думал, что подобное поведение нормально.

0

@Streletz

Нет. CompasConnector.
Возможно, это в значительной степени объясняет возникновение "тормозов". CAD-системы довольно ресурсоёмки. Обратите внимание. По данным краткого отчёта к компасу относятся 1е 4 функции с наибольшим потреблением времени. 3 из них потребляют более 20%.
Но, это пока не более чем гипотеза. Нужно смотреть на разных режимах работы профилировщика. Причём, не только краткие, но и подробные отчёты.
Работу с COM-объектом оптимизировать на порядок сложнее, чем 100% собственный код (где всё под контролем). Однако и в этом случае наверняка можно что-нибудь придумать...

0