Комментарии 62
Roslyn есть гигабайты памяти
Что то не замечал такого в VS 2017 RC
но Студия с каждой новой версией потребляет всё больше памяти
Тоже самое с VS 2017 RC, не замечал.
А мы целенаправленно следим за этим и постоянно проверяем самые разные проекты. Если солюшн маленький, то жить ещё можно. А вот когда у вас сотни проектов и миллионы строк кода, а вы что-нибудь активно рефакторите, то ситуация с памятью становится грустной (в том числе в VS 2017 RC).
ReSharper не тормозит, он работает как раньше и даже быстрее...
Visual Studio потребляет всё больше и больше памяти. Предпосылок, что будет потреблять меньше, нетНи интервьювер, ни интервьюи не понимают, о чём говорят, видимо.
Никакой лжи тут нет. Я каждый день смотрю на снэпшоты R# и Rider и прекрасно понимаю, почему имеются определённые проблемы со скоростью в VS. Тот же самый код отрабатывает мгновенно в Райдере, что наводит на определённые размышления. Вы можете самостоятельно снять профиль работы студии и Райдера и разобраться что там и как. Никого обмануть я не пытался, а просто озвучивал собственное честное мнение. Могу подписаться под каждым словом.
Насчет Rider. Я только что скачал последнюю версию, установил и проверил (в предыдущий раз я тестировал Rider где-то полгода назад). Загрузка проекта немного ускорилась, теперь вы можете конкурировать с голой VS 2015, это хорошо. Но в ответ на Rider Майкрософт в VS 2017 ускорил загрузку проектов, и VS 2017 снова сильно впереди Rider. Мультипоточный процессинг файлов при загрузке проекта – это, конечно, хорошо, но на моем ноутбуке (4200u) это заняло почти 8 минут, а до этого не работала подсветка кода (WTF?).
Я проверил свой любимый тест с readonly (ссылка выше). На удивление, в Rider автодополнение работает ещё медленнее, чем в VS 2015 + R#. Дополнить «read » до readonly я так и не смог, а на пустом проекте это работало где-то в 30% случаев. Go To Everything тоже на удивление работает заметно медленнее, чем VS 2015 + R#, пусть и достаточно быстро, чтобы не создавать проблем. Этот эксперимент показывает, что фраза «тот же самый код отрабатывает мгновенно в Райдере» – тоже ложь, тот же самый код работает также или медленнее в Rider. Ожидаемо.
Помните, я сказал, что MS активно конкурирует с Rider? А JetBrains – нет. В VS 2015 сильно улучшили подсказки, но в R#/Rider они продолжают быть страшными, как смертный грех. Третий год пошёл, вы серьёзно?
Надо сказать, что вне окна редактора и некоторых других мест Rider действительно чувствуется более плавным, чем VS 2015 + R#. Не знаю, из-за чего это происходит, может из-за нагрузки на память от «сожительства» или просто дряблого интерфейса студии, но продуктивность это не увеличивает, к сожалению. Также, это первый билд Rider который смог загрузить мой проект, позволил мне сделать изменения, собрал всё и запустил несколько тестов без падений и больших проблем. Вы делаете прогресс и создаёте какую-никакую конкуренцию, это хорошо, спасибо.
Я помню времена R# 6. Тогда были большие проблемы с производительностью новых версий, и на протяжении 5 лет в моей компании многие разработчики использовали очень сильно устаревшие версии R# именно из-за тормозов новых версий. (Их счастье прервал переход на новую студию.) Субьективно и согласно отзывам ситуация не поменялась, и более новые версии R# медленнее, чем предыдущие, но я здесь не так уверен.
Помните VS 2010? Это же был кошмар. За новый, плавный, красивый, безглючный интерфейс и новые фичи пришлось заплатить сильно вырасшим потреблением памяти. Но потом пришли 2012 и 2013 и ситуация по памяти улучшилась. VS 2015 принёс Roslyn, и хотя он действительно кушает несколько больше памяти, чем сервис до него, изменения в .NET 4.6 уменьшили потребление памяти в полтора раза. Свежезапущенная студия потребляет 120 МБ памяти! На моем проекте VS 2015 + R# редко выходят за пределы 1.5 ГБ, проблем с памятью практически нет. По отзывам и логике в VS 2017 с памятью всё ещё лучше, но личного опыта у меня недостаточно, чтобы что-то утверждать.
Общий вывод: R# тормозит даже в Rider, новые версии R# работают медленнее, чистый эффект от Rider нейтральный или отрицательный, с памятью в студии лучше, чем когда-либо.
Вам не кажется, что как минимум некорректно сравнивать производительность голой студии и студии_с_решарпером/райдера? Очевидно, решарпер будет влиять на производительность из-за 100500 фич, анализов и т.п. Если та же скорость загрузки солюшна в голой студии и райдере одинаковая, то это плохие новости для студии, поскольку райдер за это же время делает гораздо больше и дает гораздо больше фич.
По сути. Я на работе пользуюсь райдером как основной IDE уже около трех месяцев. В солюшне около 200 проектов. До этого была студия 2013 + решарпер с включенными тяжелыми фичами (solution-wide analysis, r# build, вот это все). В 2015 на моем проекте было еще хуже по памяти, пришлось вернуться на 2013.
Наблюдения:
- От запука студии до возможности начать работу запросто проходило 5 минут, до этого дикие тупняки или просто зависание UI. В райдере можно работать через минуту, если не меньше.
- Студия во время работы периодически тупила и зависала на несколько секунд даже просто при вводе текста. Если запускаешь сборку, вообще лучше ничего не трогать и не кликать в интерфейсе — виснет. Райдер в процессе работы не зависает, сборка почти не влияет на производительность (справедливости ради, последний eap пару раз в день полностью вешается секунд на 5-10, в предыдудщих такого не было).
- В студии сделать пулл или переключить ветки — это боль и скорее всего необходимость выгружать солюшн и загружать заново (см п.1), иначе виснет от минуты до бесконечности. Райдер мгновенно подтягивает изменения.
- Студия в фоне иногда запросто выжирала 80-90% цпу. Ты сидишь в браузере, а там где-то что-то происходит и тормозит вообще все. Две запущенных студии на пару выжирали 100% цпу.
- Студия падала 1-5 раз в день, видимо из-за OutOfMemory.
Как видите, мой опыт полностью противоположен вашему, мне райдер существенно повысил эффективность работы и сохранность нервов.
В JetBrains не работаю, за положительные отзывы от них денег не получаю.
Вам не кажется, что как минимум некорректно сравнивать производительность голой студии и студии_с_решарпером/райдера? Очевидно, решарпер будет влиять на производительность из-за 100500 фич, анализов и т.п. Если та же скорость загрузки солюшна в голой студии и райдере одинаковая, то это плохие новости для студии, поскольку райдер за это же время делает гораздо больше и дает гораздо больше фич.Год-два назад я бы принял это как аргумент. Но сейчас R# практически не предоставляет новых фич, которые могут замедлить загрузку проектов.
Как видите, мой опыт полностью противоположен вашемуНе вижу. Во всех ваших претензиях следует заменить «студия» на «студия с R# и Solution-wide analysis». Мне кажется, ваш комментарий лишь подтверждает мою точку зрения – решарперовский Solution-wide analysis тормозит так, что его просто невозможно использовать. Ну и немного ССЗБ.
Кстати, вот про перезагрузку проектов (переключение) я забыл написать! Да, в старых студиях перезагрузка проекта была не очень быстрой. Вместе R# это, опять же, просто невозможно было использовать – вы абсолютно правы. Причём конкретно подавляющую вину R# я экспериментально подтверждал много-много раз. Но в VS 2017 этой проблемы практически нет, проекты перезагружаются очень быстро.
Добавлено: сборка через R# Build у меня практически не нагружает саму студию. И после завершения тормозов R# нет, в отличии от нативной системы сборки. Может что-то изменилось в последних версиях?
Во всех ваших претензиях следует заменить «студия» на «студия с R# и Solution-wide analysis».
Да, но накой мне сравнивать голую студию с райдером, если это абсолютно разный уровень по фичам? Это как nokia 3310 с айфоном сравнивать, если утрировать. Я сравниваю два варианта, предоставляющих мне одинаковые возможности по функционалу.
решарперовский Solution-wide analysis тормозит так, что его просто невозможно использовать. Ну и немного ССЗБ.
Удивительно. В студии тормозит, в райдере не тормозит. Может, дело в студии?
Но в VS 2017 этой проблемы практически нет, проекты перезагружаются очень быстро.
Вы про кнопку "перезагрузить солюшн" вместо "перезагрузить проект"? Или они таки перезагрузку отдельного проекта оптимизировали?
Да, но накой мне сравнивать голую студию с райдером, если это абсолютно разный уровень по фичам? Это как nokia 3310 с айфоном сравнивать, если утрировать. Я сравниваю два варианта, предоставляющих мне одинаковые возможности по функционалу.А вы попробуйте VS 2017.
Удивительно. В студии тормозит, в райдере не тормозит. Может, дело в студии?А что есть в Rider аналог SWA? Тот процессинг файлов сразу после открытия проекта? Не увидел как-то я от него больших полезных эффектов; всякие окошки TODO продолжали загружаться при попытке их открыть. Да и подсветка кода в это время не работала.
Вы про кнопку «перезагрузить солюшн» вместо «перезагрузить проект»? Или они таки перезагрузку отдельного проекта оптимизировали?Не очень понял, что вы имеете ввиду, но да, загрузка проектов была оптимизирована.
А вы попробуйте VS 2017.
Для чего? Вы имеете ввиду голую 2017, или с тем же самым, чем я пользуюсь в 2013?
А что есть в Rider аналог SWA?
View->Tool Windows->Errors in solution открывает такое же окошко SWA, что и в студии. Это ровно та же самая фича.
Не очень понял, что вы имеете ввиду, но да, загрузка проектов была оптимизирована.
Я вот об этом нововведении 2017: Reload All Projects has been replaced with Reload Solution to support better performance of switching branches external to VS. Если действительно оптимизировали, то да, круто, но надо пробовать.
Для чего? Вы имеете ввиду голую 2017, или с тем же самым, чем я пользуюсь в 2013?Голую 2017. Как я говорил выше, у R# не так много много фич, которых нет в 2017, и они не тормозят (или не должны тормозить) загрузку проектов.
View->Tool Windows->Errors in solution открывает такое же окошко SWA, что и в студии. Это ровно та же самая фича.В таком случае, у меня SWA работает одинаково. В студии тормоза ощущаются сильнее из-за того, что выполняется в том же процессе, и, вероятно, из-за каких-то багов или несогласований с моделью студии (я имею ввиду проблемы вроде постоянного анализа после VS билда). Мне кажется, здесь вина именно R# – анализаторы Roslyn с такой проблемой тоже раз в месяц сталкиваются, но VS их принудительно выключает и предлагает включить.
Голую 2017. Как я говорил выше, у R# не так много много фич, которых нет в 2017
Серьезно? Куча рефакторингов, билд, юнит-тесты (в студии это есть, но неудобно), continuous testing, крутые навигации и поиск, посветка всяких интересных ошибок, code cleanup, генерация кода, поддержка JS, CSS, HTML с теми же самыми анализами, рефакторингами и т.п. Если говорить о райдере, то еще поддержка VCS, интеграция с issue trackers.
Я понимаю, что многие этим всем не пользуются, но я вот люблю выжимать из инструментов все, на что они способны. Когда я вижу новую фичу, которую возможно использовать на моих проектах и которая хоть немного что-то улучшает/упрощает — я начинаю ей пользоваться. Даже если она экономит мне жалкие 5 минут в день.
Мне кажется, здесь вина именно R#
Не исключаю такой возможности. Но я рассуждаю так: у меня есть на выбор два инструмента, дающих примерно одинаковые возможности. Первый работает плохо, второй хорошо. Очевидно, я выберу второй. И по существу мне без разницы, чья вина в том, что первый плох. Может, это криво написана студия. Может, решарпер криво интегрирован со студией. Может, решарпер сам по себе кривой. Мне это неинтересно, я пользуюсь ими в связке и смотрю как на единое целое.
Но учитывая, что VS + R# работает фигово, а IDEA + R# работает хорошо, я больше склоняюсь к тому, что что-то плохо в самой студии. Может, я и неправ.
Единственное, чего мне сейчас недостает в райдере — сравнимого со студией (особенно при использовании OzCode) дебаггера. В райдере он менее удобен и функционален, и пока еще там есть феерические баги.
билд, юнит-тесты (в студии это есть, но неудобно), поддержка JS, CSS, HTML с теми же самыми анализамиОстальное есть или добавляется тривиальными анализаторами/расширениями.
я вот люблю выжимать из инструментов все, на что они способны. Когда я вижу новую фичу, которую возможно использовать на моих проектах и которая хоть немного что-то улучшает/упрощает — я начинаю ей пользоваться. Даже если она экономит мне жалкие 5 минут в день.А вы не думали, что может быть тормоза этой фича у вас отнимают больше времени и нервов, чем экономит? Мне кажется, SWA именно к такому относится.
Остальное есть или добавляется тривиальными анализаторами/расширениями.
Одного супер-решения я не видел, а искать и ставить условные 10 расширений, которые между собой еще и конфликтовать могут и где-то друг-друга дублируют, не особо хочется. Решарпер все же является единым продуктом. Да и вряд ли на некоторые фичи есть аналоги. Не стоит забывать о том, что решарпер пишут вроде уже 10 лет и там накоплена огромная куча всяких тулов.
Но, конечно, я не спорю с тем, что кому-то будет достаточно голой студии и нескольких мелких экстеншнов. Тогда нет смысла ставить решарпер.
А вы не думали, что может быть тормоза этой фича у вас отнимают больше времени и нервов, чем экономит? Мне кажется, SWA именно к такому относится.
Это вполне возможно, фича тяжелая, но и полезная. Можно от нее отказаться и улучшить перформанс ценой потери части возможностей, а можно поставить райдер и сохранить фичу включенной. Я за второй вариант ) В райдере сейчас есть далеко не все, что дает решарпер, но мои потребности он покрывает. Ради остального я готов раз в неделю запустить студию.
Странное у вас отношение, на самом деле. То вам нужна каждая-каждая фича, то «мои потребности он покрывает». Мне кажется, вы используете Rider, потому что это более новая, современная, вдохновляющая среда разработки, а не из-за производительности.
Пара пакетов анализаторов на 95% покрывают рефакторинги решарпера
Я особо не интересовался этим, так что не готов дискутировать. Допускаю, что действительно для всего можно найти замену.
То вам нужна каждая-каждая фича, то «мои потребности он покрывает».
Каждая-каждая применимая. Мне не нужна поддержка JSX, например )
Из того, чем я пользовался в студии на работе, мне не хватает разве что поддержки T4, красиво мигающих квадратиков в R# build и дебаггера. Зато получил крутую поддержку VCS и отсутствие тормозов.
На личных проектах еще жалко continuous testing, но там я могу и студию использовать, т.к. проекты мелкие и не тормозит.
потому что это более новая, современная, вдохновляющая среда разработки, а не из-за производительности.
Не без этого. Доля вдохновления в этом тоже есть, но в основном все-таки тормоза достали. На мелких проектах действительно пользуюсь просто из энтузиазма, потому что в студии не тормозит и фич пока больше.
R# тормозит даже в Rider
Что такое тормозит? На каком железе? На какой ОС? Какие еще приложения рабоают параллельно?
новые версии R# работают медленнее
Откуда у вас такая инфорамция? Как вы это сравнивали? Как получить чистую производительность Reshaper'а?
чистый эффект от Rider нейтральный или отрицательный
Что такое чистый эффект? Для меня, например, эффект от Rider'а просто огромен:
1) наконец появился (появиться) конкурент студии;
2) Rider кросплатформенный. Для многих (для меня в частности) это просто праздник и возможность ( наконец-то) использовать Linux (Mac).
с памятью в студии лучше, чем когда-либо
К сожалению, не могу сказать про 2017 RC (буду ждать RTM), но в 2015 есть над чем еще работать. Хотя да, в Microsoft действительно серьезно занялись этой проблемой.
Ну и последний аргумент: Rider еще не готов и не выпущен. И как вы сами заметили, он все лучше и лучше. Тоже можно сказать и про студию 2017.
Что такое тормозит? На каком железе? На какой ОС? Какие еще приложения рабоают параллельно?На любом. На любой. Не важно.
Откуда у вас такая инфорамция? Как вы это сравнивали? Как получить чистую производительность Reshaper'а?Прочитайте комментарий заново.
Что такое чистый эффект?Словарь
Что такое тормозит? На каком железе? На какой ОС? Какие еще приложения рабоают параллельно?
На любом. На любой. Не важно.
Еще раз пошу прощения, но это не инженерный ответ (подход). Возможно я ошибаюсь, но у меня сложилось впечатление, что вам Resharper просто не нравиться и(или) доставляет дискомфорт. Может ну его? Тем более, похоже, студия вас полностью устраивает.
Откуда у вас такая информация? Как вы это сравнивали? Как получить чистую производительность Resharper'а?
Прочитайте комментарий заново.
Прочитал. Извините, но это даже не намек на тестирование. И опять же, крайне интересно узнать как вы смогли измерить «чистую» производительность именно Resharper'а.
Производительность конкретно R# измеряется достаточно просто – по сравнению с ним, влияние других компонентов на производительность пренебрежимо мало. То есть, производительность всего пакета стремится к производительности решарпера и в утрированном случае ему равна.
А он R# в VS 2017 я уже отказался.
Всё-таки прочитайте мой комментарий. Целиком. Внимательно. Там есть ссылки на источники для ленивых. В этих источниках куча подтверждений моих слов о том, что R# тормозит на абсолютно любом железе.
Перечитал ваш комментарий (целиком и предельно внимательно). Перечитал все по ссылкам. Прошу прощения, но не нашел подтверждение ваших слов про «абсолютно». Мой опыт использования R# (> 4 лет) на разном железе и разных проектах говорит об обратном. Да, без сомнения, «голая» студия часто «быстрее». Но будь она таким отличным инструментом, кто бы стал покупать и использовать R#?
Кстати, вы не могли не обратить внимание, что подавляющее большинство жалоб на R# (по ссылкам) именно на комбинацию VS 2105 + R#. И, к тому же, есть комментарии что на VS 2013, 2012 + R# все отлично. На мой взгляд, это именно то о чем говорил Андрей и спрашивал Алексей: студия разбухает и решарперу меньше места для «маневров» + конфликты с Roslyn'ом.
Производительность конкретно R# измеряется достаточно просто – по сравнению с ним, влияние других компонентов на производительность пренебрежимо мало. То есть, производительность всего пакета стремится к производительности решарпера и в утрированном случае ему равна.
Не согласен с вами. Особенно если рассматривать VS 2015 + Roslyn. А студия у вас выходит совсем уж идеальной и невесомой. Если бы не был с ней «знаком» 14 лет и 7 (вроде) релизов, может бы и поверил :).
А он R# в VS 2017 я уже отказался.
Рад за вас. Действительно. Обязательно гляну сам: скорее всего просто срабатывает старая привычка не использовать продукты MS до первого SP1.
Хотя опять же, если VS 2013 настолько хороша, то чего вы мучаетесь и используете R#? Выходит вас или заставляют (не хочу в это верить), или таки вы о чем-то умалчиваете и решарпер решает какие-то ваши (похоже весьма специфичные) задачи и «проблемы» с производительностью просто плата за эти «плюшки».
к сожалению когда встраиваешь R# очень тяжело оценить производительность.
ибо мало того что становится два анализатора кода, так они еще и толкаются внутри одного процесса.
(то есть идут не только издержки R#)
на практике для себя я отказался от R# после выхода VS2015, написал пару рефакторингов, которых не хватало.
все летает, меня устраивает.
может я просто не ЦА R#, кто знает.
— дубль ---
@DreamWalker какой процент кода написан на Kotlin в Rider?
От себя — очень очень хочу F#
Он работает внутри процесса, и это большая проблема, потому что год 2016-й, а Visual Studio — всё ещё 32-битный процесс
возможно задам глупый вопрос, а почему не вынести свои потоки в отдельный процесс и организовать межпроцессное взаимодействие?
В целом — хорошее интервью.
Спасибо за дополнение! Рад, что у вас нет проблем со скоростью и интерфейсом, Xamarin действительно очень прокачался за последнее время. Но хотелось бы сказать, что потребности у народа разные: я постоянно общаюсь с Xamarin-разработчиками, отзывы о платформе у всех различные. Очень здорово, что на рынке имеется подобный инструмент, но судя по всему направления для развития всё ещё есть. =)
Интересует вопрос версий Rider: будет ли аналог Community как у IntelliJ IDEA?
Ещё не решили. Сначала нужно дописать продукт, а потом будем думать про лицензирование. =)
Что касается студентов, то им в любом случае полагается бесплатная подписка на All Products, куда Rider несомненно войдет.
Только не надо говорить мне, что «тру-программист» всегда работает только в англоязычных программах!
«Хаос в .NET-мире — разумная цена за скорость развития платформы»: интервью с Андреем Акиньшиным (JetBrains)