Собственно сабж.
Во время отладки приложения он проявляет свои нехорошие свойства в гипертрофированой форме (тормозит жутко), хотя как раз в это время нет абсолютно никакой необходимости в его фичах, связаных с анализом кода.
Я считаю что если реализовать сабж, то юзабельность решарпера повысится процентов на 50, по крайней мере для меня.
Если есть возможность, прошу описать костыль, при помощи которого можно решать проблему проще и быстрее, чем отключением решарпера через меню перед каждой отладкой.
Re: Заставить решарпер отключаться во время отладки.
Здравствуйте, torquemada, Вы писали:
T>Собственно сабж. T>Во время отладки приложения он проявляет свои нехорошие свойства в гипертрофированой форме (тормозит жутко), хотя как раз в это время нет абсолютно никакой необходимости в его фичах, связаных с анализом кода. T>Я считаю что если реализовать сабж, то юзабельность решарпера повысится процентов на 50, по крайней мере для меня. T>Если есть возможность, прошу описать костыль, при помощи которого можно решать проблему проще и быстрее, чем отключением решарпера через меню перед каждой отладкой.
Создаем макрос:
Public Module SwithResharperModule
Sub SwitchResharper()
For Each addIn As EnvDTE.AddIn In DTE.AddIns
If addIn.Name.ToLower.Contains("resharper") Then
addIn.Connected = Not addIn.Connected
Exit Sub
End If
Next
End Sub
End Module
Дальше, добавляем на панели в студию этот макрос, можно установить картинку.
Re[2]: Заставить решарпер отключаться во время отладки.
Здравствуйте, mescalit0, Вы писали:
M>Создаем макрос: M>Public Module SwithResharperModule
... M>End Module M>Дальше, добавляем на панели в студию этот макрос, можно установить картинку.
Решение полезное и на удивление простое, спасибо, жалею что раньше не додумался до такого, но тем не менее это не решение.
Такой вариант ускоряет весь процесс ровно на 4 клика мышки, а это около 4 секунд, в то время, как сам процесс отключения решарпера занимает куда больше времени(особенно если в редакторе открыт большой файл, что само по себе для дебаг режима уже парадоксально). Нужно учесть так же то, что всё время приходится помнить о том, чтобы случайно не дай бог не войти в дебаг-режим с решарпером.
Я надеялся что авторы продукта посоветуют какой то более быстрый способ отключения, который наверняка присутсвует в API решарпера. А так же может кто то подсказать, если для этого писать addin к студии (пусть даже для банального отключения плагина, как описано в приведённом выше макросе), то можно как то привязаться к событию входа в дебаг-режим ? Собственные поиски и эксперименты ни к чему не привели.
Re[3]: Заставить решарпер отключаться во время отладки.
Здравствуйте, torquemada, Вы писали:
T>Я надеялся что авторы продукта посоветуют какой то более быстрый способ отключения, который наверняка присутсвует в API решарпера.
Такого способа нет.
Вообще, мы пытаемся решить проблему с другой, ИМХО более правильной стороны. Т.е. сделать так, чтоб РеШарпер не тормозил и тогда не требовалось бы его быстро отключать.
Собственно, у нас он особо и не тормозит и отладке не мешает.... Напиши плиз подробнее — когда и в какой момент тормозит, кокой решарпер и что за проект.
С уважением, Евгений
JetBrains, Inc. "Develop with pleasure!"
Re[4]: Заставить решарпер отключаться во время отладки.
Здравствуйте, xvost, Вы писали:
X>Собственно, у нас он особо и не тормозит и отладке не мешает.... Напиши плиз подробнее — когда и в какой момент тормозит, кокой решарпер и что за проект.
И сколько свободной оперативной памяти на машине остаётся после запуска приложения. Если памяти мало, то это нормальное поведение.
... << RSDN@Home 1.2.0 alpha 4 rev. 1136>>
Re[4]: Заставить решарпер отключаться во время отладки.
Здравствуйте, xvost, Вы писали:
X>Собственно, у нас он особо и не тормозит и отладке не мешает.... Напиши плиз подробнее — когда и в какой момент тормозит, кокой решарпер и что за проект.
Тормозит он к сожалению практически всегда, за исключением маленьких файлов, не больше 100 строк.
В данном случае я задумался насчёт того, что особенно сильно тормоза меня всегда мучили при переходе с ним в режим отладки проекта. В этот момент, если, к примеру, открыт файл строк эдак в 1000, то секунд 30-60 можно смело курить, поскольку решарпер активно начинает анализировать файл, конкурируя с потоком задач отладчика, причём даже в том случае, если перед отладкой он им уже был проанализирован, и проект был полностью сохранён. Если же в этот момент решарпер был отключен, то отладка начинается очень быстро, даже если файл будет в 10000 строк.
Решарпером пользуюсь очень давно, т.е. могу отличать глюки собственного компьютера от тормозов решарпера.
Памяти 2,5 гига(соответственно одноканальный режим), проц P4-3,2 (гипертрейдинг отключен). Ничего связаного с наличием свободной памяти я не обнаружил. т.е. он тормозит когда свободно 2 гига и точно так же тормозит когда уже используется своп. Причём это в обоих случаях субьективно выглядит как активное использование свопа, хоть и по винту этого не скажешь.
Студия 2008 TFS с SP1(не SP1TFS).
Решарпер 4.5.1158.11
А может быть возможно как то реализовать сабж поместив какой то эдемент (например кнопку) в рабочее пространство отладчика, чтобы в момент, когда она появляется в рабочем пространстве, срабатывало какое то её событие ?
И ещё. Я нашёл команду решарпера EnableDaemon, которая значительно быстрее отключает анализ кода, чем деактивация плагина, но у меня никак не вышло до неё добраться из шелла, не подскажете как ?
Re[5]: Заставить решарпер отключаться во время отладки.
Ещё как вариант добавить несколько команд, которые будут аналогичны студийным из меню debug с той разницей, что перед выполнением будут делать "DisableDaemon" для текущего файла. Не думаю что возьмусь делать это сам, т.к. слишком много ньюансов всплывает, это просто подсказака для команды, занимающейся решарпером.
Хочу только подчеркнуть, что если это реализуете прозрачно для пользователей, то про самые большие тормоза (во время отладки) решарпера народ забудет.
Я вообще для себя уже вижу очень полезныым такой вариант работы решарпера, когда по умолчанию решарпер всегда off, и только при желании включать анализ файла (кстати, это можно забиндить на клик по индикатору его состояния справа вверху от полосы прокрутки). Ведь по сути как помощник он нужен далеко не всегда, но не хотелось бы его отключать.
Конечно для людей, которые впервые знакомятся с ним предложеное мной его поведение может показаться странным, но ведь можно поставить галку в настройках для этого (например при отключеной галке "Enable code analysis" дать возможность включать анализ как описано выше).
В конце концов гораздо проще кликнуть мышкой чтобы включить в нужное время анализ кода, чем испытывать невыносимые тормоза каждый раз, когда анализ кода не нужен, а не нужен он практически всегда.
Re[6]: Заставить решарпер отключаться во время отладки.
Здравствуйте, Блудов Павел, Вы писали:
БП>А кроме решарпера что ещё установлено в студии? VisualSvn? Дизайнеры формочек от Infragistics/DeveloperExpress?
Больше ничего.
Я же говорю, решарпером давно пользуюсь(года 3) и знаю что есть его тормоза, а что тормоза "косвенно его".
За время пользования решарпером кучу раз переставлял студию, систему. Каждый раз после того, как ставлю студию, в первую очередь после неё ставлю решарпер, а потом уже как понадобится AnkhSVN, но в том и дело, что тормоза решарпера очень стабильны, не зависят ни от чего кроме него самого (ну и разумеется при включеном решарпере пропорционально размеру открытого файла). Причём, всегда одна довольно убедительная закономерность — как только отключаю решарпер через "tools\add-in manager", тормоза сразу проходят(в последнее время забиндил EnableDaemon, результат почти такой же). Пробовал студию в dottrace запускать, ничего нового для себя не обнаружил — самые "тяжёлые" вещи всегда начинаются с "Jetbrains...".
Но это фигня всё, я почти привык включать решарпер только тогда, когда он нужен, но хочется делать это быстро, и я за себя могу сказать что планка юзабельности решарпера для меня повысилась бы в разы, если бы такая возможность появилась.
Ну не сможете вы, сколько бы не бились заставить решарпер быть незаметным в плане ресурсов для пользователя, это же очевидно, почему бы не подойти к вопросу практически ?
Re[8]: Заставить решарпер отключаться во время отладки.
Кстати, по причине близкой к сабжу мне пришлось вслепую отлаживать scout plugin.
там как я понял получилась вообще какая то чудесная штука вроде того, что студия с решарпером и так долго запускается (обычно он у меня из автозапуска выключен), плюс каждый проект с ним загружается раз в несколько дольше, но когда студия оказалась сама подключеной к отладчику с включеным решарпером, и загруженым в него плагином, мне не хватило терпения дождаться вообще какого то результата даже после довольно продожительного перекура(студия висела на стадии загрузки кеша решарпера, или что то в этом роде). Вот здесь то уж никакими быстрыми отключениями решарпера не обойтись впринципе.
Но это уже экзотика.
Re[9]: Заставить решарпер отключаться во время отладки.
Здравствуйте, torquemada, Вы писали:
T>Кстати, по причине близкой к сабжу мне пришлось вслепую отлаживать scout plugin.
R# требователен к ресурсам, но чтобы так как увас никогда не было. В основном тормоза при открытии больших файлов, например открыть *.designer.cs для сложной формы.
Иногда при наборе текста, и то только в коде форм, как я понял тут анализируется и *.designer.cs. Причем больше всего они чувствуются на слабой тачке.
Отлаживаю и разрабатываю плагины к R# уже больше года на ноуте 2,4 Core 2 Duo, 4Gb RAM и винт 320 Gb (5400) — полет очень даже нормальный.
Здравствуйте, torquemada, Вы писали:
T>Но это уже экзотика.
Тем не менее это не нормально. У меня вот сейчас студия с решарпером, в которой открыт проект самого решарпера, рядом другая студия с решарпером под отладкой. И вроде бы все вполне нормально шевелится.
И всё таки.
Предлагаю галке в настройках решарпера с названием "Enable code analysis" такой функционал:
при включеной — всё как обычно
при выключеной — по умолчанию для каждого файла анализ не производится, но при желании его можно включить при помощи "EnableDaemon" (почему бы не прикрутить функционал "EnableDaemon" ещё и к цветномй квадратику состояния анализа файла справа от полосы прокрутки ?). Ещё лучше я думаю, чтобы состояние "EnableDaemon" в таком случае для каждого файла не запоминалось вообще, т.е. анализ остовался активным вплоть до момента перехода к просмотру другого файла.
Никакой функционал и существующая логика работы решарпера от предложеной схемы не страдает.
Re[11]: Заставить решарпер отключаться во время отладки.
Купите нормальный проц (хотя бы Core2Duo) — и тормоза уменьшатся.
Лично меня дико напрягают тормоза с ASP.NET — даже на моей не слабой машине (Core2Quad 4x2.4 GHz, 4GB DDR1066 RAM, Vista 64bit, на работе то же самое, но ОС XP 32bit) подтормаживает очень капитально Правда по опыту использования nightly от 4.1 я в этот раз воздержался от использования EAP-билдов 4.5 — уж очень глючные были они, так что чё там с этим в 4.5 — не знаю (как будет релиз — посмотрим).
K>Купите нормальный проц (хотя бы Core2Duo) — и тормоза уменьшатся.
А вы уверены, что количество процессоров здесь играет хоть какую то роль ?
Я не уверен, по крайней мере после включения гипертрейдинга в диспетчере задач чётко видно что один devenv.exe кушает только один процессор.
Если это действительно так, то могу предположить что ваш Core2Quad 2.4GHz в конкретно этой ситуации несколько уступает моему старому доброму P4 3.2GHz.
Re[13]: Заставить решарпер отключаться во время отладки.
Здравствуйте, torquemada, Вы писали:
T>А вы уверены, что количество процессоров здесь играет хоть какую то роль ? T>Я не уверен, по крайней мере после включения гипертрейдинга в диспетчере задач чётко видно что один devenv.exe кушает только один процессор. T>Если это действительно так, то могу предположить что ваш Core2Quad 2.4GHz в конкретно этой ситуации несколько уступает моему старому доброму P4 3.2GHz.
Нет, это не так. Даже разработчики тут писали что-то на тему того, что распараллеливают работу. Более того, при наличии хотя бы двух ядер решарперовский процессинг (даже если он однопоточный, просто он выполняется в отдельном от гуёвого потока) со свистом уходит на отдельное ядро, в то время как второе занимается обработкой сообщений, т.е. отвечает за взаимодействие пользователя с гуёй... Так что не факт что ваш проц тут быстрее — ибо ему приходится и цикл сообщений крутить, и подсветку обновлять, и процессингом заниматься.
Да и вообще на многоядерных процах больше вероятность поймать багу в разрабатываемом многопоточном приложении (ибо тут есть _реальное_ параллельное исполнение потоков), а не пытаться выловить их на продакшене (все известные мне сервера многоголовые), так что ИМХО для девелоперов многоядерный проц просто MUST HAVE...
Здравствуйте, torquemada, Вы писали:
T>Если это действительно так, то могу предположить что ваш Core2Quad 2.4GHz в конкретно этой ситуации несколько уступает моему старому доброму P4 3.2GHz.
Не уступает, а весьма прилично превосходит. Там даже одно ядро будет значительно быстрее.
... << RSDN@Home 1.2.0 alpha 4 rev. 1138 on Windows Vista 6.1.7000.0>>
Правда по опыту использования nightly от 4.1 я в этот раз воздержался от использования EAP-билдов 4.5 — уж очень глючные были они, так что чё там с этим в 4.5 — не знаю (как будет релиз — посмотрим).
