5 октября 2016-го года вышел Visual Studio «15» Preview 5. Команда разработчиков сфокусировалась на повышении производительности IDE. В этой статье мы рассмотрим некоторые из улучшений. Запускайте инсталлятор и, пока он устанавливается, читайте о нововведениях в этой статье или в оригинальных release notes.
Я хотел бы начать с видео, которое очень хорошо показывает рост производительности в данном превью. Здесь показана загрузка проекта Roslyn, которая ранее занимала 60 секунд, а в новом превью полностью заканчивается уже к 30-ой секунде.
Ускорение загрузки является результатом нескольких усовершенствований, таких как, например, легковесная загрузка проектов и загрузка по требованию расширений. Весь список нововведений включает следующие вещи:
Меньшее время загрузки благодаря новой «легковесной» загрузке. Если у вас есть сотня проектов — это не значит, что с каждым из них вы будете работать прямо сейчас. VS “15” даёт возможность редактировать, собирать и отлаживать код без необходимости ждать загрузки всех проектов. Вы можете протестировать эту возможность с управляемыми (managed) проектами, путём включения галочки «Lightweight Solution Load» в Tools -> Options -> Projects and Solutions.
Ускорение загрузки благодаря отложенной загрузке расширений. Идея проста: загружать расширения тогда, когда они понадобятся, а не сразу при запуске Visual Studio. В данном превью мы начали работать над тем, чтобы загружать наши расширения для Python и Xamarin только когда (и если!) они понадобятся. В будущем все расширения (как от Microsoft, так и от сторонних фирм) будут работать по этой схеме. Если вам интересно, как то или иное расширение влияет на скорость загрузки Visual Studio, то теперь вы можете это узнать, открыв в меню Help -> Manage Visual Studio Performance. Вы разрабатываете своё расширение? Мы вскоре опубликуем рекомендации на счёт того, как перевести его на новую схему работы с отложенной загрузкой.
Перемещение некотрых подсистем, активно использующих память, из главного процесса Visual Studio в отдельные процессы. Мы выделили некоторые компоненты, такие как Git Source Control, Javascript и Typescript-сервисы в отдельные процессы. Это позволило уменьшить влияние от пауз в их работе на отзывчивость пользовательского интерфейса в главном процессе Visual Studio. Кроме того, это позволило уйти дальше от лимита в 4 ГБ памяти на один процесс, налагаемый 32-битными версиями операционной системы. Мы планируем продолжить работу по выделению подсистем в отдельные процессы в следующих релизах.
Более быстрая загрузка, редактирование и отладка С++ проектов. Мы отдельно повысили производительность работы с С++ кодом. Посмотрите вот это видео. Вы можете включить данную возможность для своих проектов с помощью опции «Enable Faster Project Load», которая находится в Tools -> Options -> Text Editor -> C/C++ -> Experimental. Мы также внесли изменение в линковщик и механизм загрузки PDB-файлов для того, чтобы сделать запуск отладчика значительно более быстрым, а также уменьшить потребление памяти во время отладки.
Улучшена скорость работы Git, отладки и редактирования XAML. Мы ускорили работу с Git путём замены использования libgit2 на git.exe. Скорость работы отладчика повышена за счёт оптимизации затрат на инициализацию, использование IntelliTrace и Diagnostic Tools. Также удалось убрать несколько задержек, возникающих при редактировании XAML-файлов.
Это только начало и мы продолжаем работать над тем, чтобы сделать Visual Studio быстрее, отзывчевее, более экономной к памяти. В следующих статьях блога команды Visual Studio мы постараемся детальнее рассказать о каждом из нововведений.
В Visual Studio “15” есть также ряд новых возможностей, направленных на повышение производительности труда программиста
Фильтры IntelliSense теперь доступны для C#, VB и C++. При использовании сложных API вы можете сузить область до лишь того типа объектов, который вам интересен в данный момент (например, методов, свойств или событий). В C# и Visual Basic мы определяем «требуемый тип», который ожидается в текущей позиции и заранее выбираем из списка сущности соответствующего типа. Это ускоряет ваш набор кода и убирает необходимость перебирать ненужные пункты в списке.
В С++ у нас также появилась экспериментальная поддержка аналогичной функциональности, она называется Predictive IntelliSense и точно так же избавляет программиста от листания длинных списков автодополнения. Будут показываться только актуальные в данном контексте подсказки, отсортированные по вероятности того, насколько они могут быть полезны. Данную возможность можно включить в Tools > Options > Text Editor > C/C++ > Experimental.
Для XAML мы добавили возможность автодополнения для x:Bind, что позволяет удобно биндиться к свойствам и событиям. Автодополнение пространств имён позволяет дописывать префиксы, если ссылка на пространство имён уже существует. IntelliSense для XAML также был обновлён таким образом, чтобы отфильтровывать неподходящие типы и свойства.
Для JavaScript мы полностью переписали сервис поддержки IntelliSense. Раньше движок JavaScript непрерывно выполнял набранный код по ходу того, как вы его печатали. Это давало возможность получить списки автодополнения на рантайме. Подобный динамизм — хорошая штука и вообще суть JavaScript, однако не лучший способ помощи программисту при редактировании кода. Новый сервис использует статический анализ для более качественного автодополнения, включая все возможности ES6/ES7.
Для того, чтобы помочь вам поддерживать ваш код в хорошем, читаемом состоянии мы добавили ещё больше быстрых правок (Quick Actions) и возможностей рефакторинга для C# и Visual Basic. Например, «Move Type to Matching File» перемещает тип в новый файл, имеющий такое же имя. «Sync File and Type Name» позволяет переименовать тип таким образом, чтобы его имя соответствовало названию файла, в котором он находится (или наоборот). И, наконец, «Convert to Interpolated String» позволяет задействовать доступную в C# 6.0 и VB14 возможность использования интерполлированых строк вместо «string.Format».
Осмотреться вокруг и понять, где находишься бывает непросто при работы с большой кодовой базой. Мы добавили несколько новых возможностей, связанных с навигацией. Go To: (Ctrl +, или Ctrl + T) позволит вам быстро найти файлы, типы, методы или другие типы сущностей в вашем коде.
Найти все ссылки (Shift+F12) помогает вам разобраться в связях кода, даже в очень больших кодовых базах. Эта возможность позволяет группировать, фильтровать, сортировать и искать результаты, а для некоторых языков также поддерживает выделение цветами, что позволяет лучше сориентироваться и понять зависимости в коде.
В Preview 5 мы добавили новую экспериментальную возможность Run to Click. Вам больше не нужно устанавливать временные точки останова для того, чтобы пропустить не интересный вам блок и остановиться на конкретной строке. При остановке в отладчике просто кликните на иконке, которая появится на нужной вам строке. Отладчик запустит выполнение кода с текущего места и до позиции, на которую вы указали. Вы можете включить данную возможность в Debug > Options > Enable Run to Click.
В данной статье расказано не всё о данном превью, полный список нововведений есть в release notes.
Несколько важным особенностей данного превью. Прежде всего, оно является неподдерживаемым, а значит не стоит пока использовать его в критичных производственных процессах. Во-вторых, данное превью может быть установлено параллельно с предыдущими версиями Visual Studio, но не может быть установлено параллельно с другими превью Visual Studio “15”, а значит их придётся удалить до его установки. Подробнее об этом можно прочесть в часто задаваемых вопросах.
Как всегда, обратная связь приветствуется. Для сообщений об ошибках вы можете воспользоваться встроенной в Visual Studio и инсталлятор функцией Report a Problem. Оставить свой отзыв можно на портале разработчиков. Советы и предложения принимаются на UserVoice
Значительный шаг вперёд в производительности и экономии памяти
Я хотел бы начать с видео, которое очень хорошо показывает рост производительности в данном превью. Здесь показана загрузка проекта Roslyn, которая ранее занимала 60 секунд, а в новом превью полностью заканчивается уже к 30-ой секунде.
Ускорение загрузки является результатом нескольких усовершенствований, таких как, например, легковесная загрузка проектов и загрузка по требованию расширений. Весь список нововведений включает следующие вещи:
Меньшее время загрузки благодаря новой «легковесной» загрузке. Если у вас есть сотня проектов — это не значит, что с каждым из них вы будете работать прямо сейчас. VS “15” даёт возможность редактировать, собирать и отлаживать код без необходимости ждать загрузки всех проектов. Вы можете протестировать эту возможность с управляемыми (managed) проектами, путём включения галочки «Lightweight Solution Load» в Tools -> Options -> Projects and Solutions.
Ускорение загрузки благодаря отложенной загрузке расширений. Идея проста: загружать расширения тогда, когда они понадобятся, а не сразу при запуске Visual Studio. В данном превью мы начали работать над тем, чтобы загружать наши расширения для Python и Xamarin только когда (и если!) они понадобятся. В будущем все расширения (как от Microsoft, так и от сторонних фирм) будут работать по этой схеме. Если вам интересно, как то или иное расширение влияет на скорость загрузки Visual Studio, то теперь вы можете это узнать, открыв в меню Help -> Manage Visual Studio Performance. Вы разрабатываете своё расширение? Мы вскоре опубликуем рекомендации на счёт того, как перевести его на новую схему работы с отложенной загрузкой.
Перемещение некотрых подсистем, активно использующих память, из главного процесса Visual Studio в отдельные процессы. Мы выделили некоторые компоненты, такие как Git Source Control, Javascript и Typescript-сервисы в отдельные процессы. Это позволило уменьшить влияние от пауз в их работе на отзывчивость пользовательского интерфейса в главном процессе Visual Studio. Кроме того, это позволило уйти дальше от лимита в 4 ГБ памяти на один процесс, налагаемый 32-битными версиями операционной системы. Мы планируем продолжить работу по выделению подсистем в отдельные процессы в следующих релизах.
Более быстрая загрузка, редактирование и отладка С++ проектов. Мы отдельно повысили производительность работы с С++ кодом. Посмотрите вот это видео. Вы можете включить данную возможность для своих проектов с помощью опции «Enable Faster Project Load», которая находится в Tools -> Options -> Text Editor -> C/C++ -> Experimental. Мы также внесли изменение в линковщик и механизм загрузки PDB-файлов для того, чтобы сделать запуск отладчика значительно более быстрым, а также уменьшить потребление памяти во время отладки.
Улучшена скорость работы Git, отладки и редактирования XAML. Мы ускорили работу с Git путём замены использования libgit2 на git.exe. Скорость работы отладчика повышена за счёт оптимизации затрат на инициализацию, использование IntelliTrace и Diagnostic Tools. Также удалось убрать несколько задержек, возникающих при редактировании XAML-файлов.
Это только начало и мы продолжаем работать над тем, чтобы сделать Visual Studio быстрее, отзывчевее, более экономной к памяти. В следующих статьях блога команды Visual Studio мы постараемся детальнее рассказать о каждом из нововведений.
Улучшение продуктивности
В Visual Studio “15” есть также ряд новых возможностей, направленных на повышение производительности труда программиста
Редактирование кода
Фильтры IntelliSense теперь доступны для C#, VB и C++. При использовании сложных API вы можете сузить область до лишь того типа объектов, который вам интересен в данный момент (например, методов, свойств или событий). В C# и Visual Basic мы определяем «требуемый тип», который ожидается в текущей позиции и заранее выбираем из списка сущности соответствующего типа. Это ускоряет ваш набор кода и убирает необходимость перебирать ненужные пункты в списке.
В С++ у нас также появилась экспериментальная поддержка аналогичной функциональности, она называется Predictive IntelliSense и точно так же избавляет программиста от листания длинных списков автодополнения. Будут показываться только актуальные в данном контексте подсказки, отсортированные по вероятности того, насколько они могут быть полезны. Данную возможность можно включить в Tools > Options > Text Editor > C/C++ > Experimental.
Для XAML мы добавили возможность автодополнения для x:Bind, что позволяет удобно биндиться к свойствам и событиям. Автодополнение пространств имён позволяет дописывать префиксы, если ссылка на пространство имён уже существует. IntelliSense для XAML также был обновлён таким образом, чтобы отфильтровывать неподходящие типы и свойства.
Для JavaScript мы полностью переписали сервис поддержки IntelliSense. Раньше движок JavaScript непрерывно выполнял набранный код по ходу того, как вы его печатали. Это давало возможность получить списки автодополнения на рантайме. Подобный динамизм — хорошая штука и вообще суть JavaScript, однако не лучший способ помощи программисту при редактировании кода. Новый сервис использует статический анализ для более качественного автодополнения, включая все возможности ES6/ES7.
Быстрые правки и рефакторинг
Для того, чтобы помочь вам поддерживать ваш код в хорошем, читаемом состоянии мы добавили ещё больше быстрых правок (Quick Actions) и возможностей рефакторинга для C# и Visual Basic. Например, «Move Type to Matching File» перемещает тип в новый файл, имеющий такое же имя. «Sync File and Type Name» позволяет переименовать тип таким образом, чтобы его имя соответствовало названию файла, в котором он находится (или наоборот). И, наконец, «Convert to Interpolated String» позволяет задействовать доступную в C# 6.0 и VB14 возможность использования интерполлированых строк вместо «string.Format».
Навигация по коду
Осмотреться вокруг и понять, где находишься бывает непросто при работы с большой кодовой базой. Мы добавили несколько новых возможностей, связанных с навигацией. Go To: (Ctrl +, или Ctrl + T) позволит вам быстро найти файлы, типы, методы или другие типы сущностей в вашем коде.
Найти все ссылки (Shift+F12) помогает вам разобраться в связях кода, даже в очень больших кодовых базах. Эта возможность позволяет группировать, фильтровать, сортировать и искать результаты, а для некоторых языков также поддерживает выделение цветами, что позволяет лучше сориентироваться и понять зависимости в коде.
Отладка
В Preview 5 мы добавили новую экспериментальную возможность Run to Click. Вам больше не нужно устанавливать временные точки останова для того, чтобы пропустить не интересный вам блок и остановиться на конкретной строке. При остановке в отладчике просто кликните на иконке, которая появится на нужной вам строке. Отладчик запустит выполнение кода с текущего места и до позиции, на которую вы указали. Вы можете включить данную возможность в Debug > Options > Enable Run to Click.
Самое время попробовать
В данной статье расказано не всё о данном превью, полный список нововведений есть в release notes.
Несколько важным особенностей данного превью. Прежде всего, оно является неподдерживаемым, а значит не стоит пока использовать его в критичных производственных процессах. Во-вторых, данное превью может быть установлено параллельно с предыдущими версиями Visual Studio, но не может быть установлено параллельно с другими превью Visual Studio “15”, а значит их придётся удалить до его установки. Подробнее об этом можно прочесть в часто задаваемых вопросах.
Как всегда, обратная связь приветствуется. Для сообщений об ошибках вы можете воспользоваться встроенной в Visual Studio и инсталлятор функцией Report a Problem. Оставить свой отзыв можно на портале разработчиков. Советы и предложения принимаются на UserVoice
Поделиться с друзьями
a553
Ещё немного, ещё чуть-чуть, и можно будет выкинуть решарпер!
alemiks
точно, ибо решарпер будет встроен в rider :P
ad1Dima
Ставить Java чтоб прогать под .net… Rider будет полезен на других осях.
mezastel
Вам шашечки или ехать?
ad1Dima
Ехать, поэтому и не понимаю, зачем Java/Rider винде, кроме как для конкуренции.
mezastel
Затем что по сравнению с VS, Rider работает быстрее в разы.
ad1Dima
По сравнению с 2015 студией, включённым в ней рослином и решарпером?
(как-то от создателя хочется что-то большее, чем жирный текст)
mezastel
Я уже не с создателем :) Но если серьезно, то это причина номер 1 для ухода со Студии. Студия генерит бешеные тормоза, части ее инфраструктуры катастрофично плохо спроектированы (нарпимер добавление референса в проект решено с квадратичной!!! сложностью). Это никому не нужно.
К тому же, в Студии при инсталляции слишком много багажа — после воплей разгневаных разработчиков его конечно урезали (а то раньше было навязывание windows phone sdk, например), но проблема все еще остается. Еще следует упомянуть всякие дизайнеры которыми никто никогда и не пользовался — например визуальные дизайнеры для веба или WPF. Это все смело можно выкидывать.
Ну и наконец Roslyn. Его в Студии не отключить, а следовательно 600Mb оперативки вы просто подарили непонятно за что. Несмотря на то, что Рослин во многих смыслах реализован более корректно чем решарпер (например, все иммутабельно), реализовано это поздно и не полностью (то есть для ограниченного набора языков). Соответственно, в Решарпере рослиновские фичи редактирования кода есть, и скорее всего они реализованы более корректно. Нарпимер, возьмите Rename когда переменная протаскивается через лямбды. В Решарпере ренейм учтет все зависимости, в рослине получить ломаный код — тривиально.
В конечном счете, выбирать вам. И да, не вам одному неприятен JVM стэк, но если это дает огромный прирост по скорости (и следовательно, вашей же производительности), то почему бы и нет?
ad1Dima
Это как раз и решили в 15шке. см прошлый превью.
И интересно посмотреть пример протаскивания через лямбды при котором у рослина ломается. Я как-то вообще стараюсь через них не протаскивать во избежание утечек. А сейчас две вложенных лямбды рослин сожрал.
ad1Dima
Я все ещё хочу пример:
nZeus
только вот в решарпере порой заменить локальную переменную в методе занимает чуть ли не минуту
ad1Dima
Зачем это мне отвечать-то?
nZeus
да, не вам. С уровнем проблемы )
INC_R
Даже по сравнению с 2013 студией с решарпером, без всякого рослина, Rider уже прекрасен. С вашего позволения, пример с рабочего проекта.
На солюшне, в котором примерно 200 проектов, во время загрузки студии можно уходить пить чай. В процессе работы она тоже частенько подвисает и периодически падает. При билде сложно даже ходить по коду. При необходимости сделать pull или checkout — почти гарантированная необходимость перезагружать солюшн или студию. И даже в фоне, когда я сижу в другом приложении, студия что-то делает и периодически выжирает 80-90% процессора.
Пробовал студию 2015; субьективно, стало еще хуже.
Rider уже сейчас не страдает ни одной из этих проблем. При его пока еще многочисленных детских болезнях и большом количестве всяких багов и нереализованных фич, работать в нем уже гораздо удобнее и приятнее. За последние полторы недели вообще не было необходимости запускать студию.
Наверное, если выключить половину фич решарпера, то и в студии можно было бы работать, но в Rider все то же самое летает.
ad1Dima
Нельзя сказать, что открывается быстро, но чай максимум заварить успеешь.
INC_R
Но все равно долго ведь. И все равно есть проблемы в процессе самой работы (падает, виснет, тормозит...)
В rider же можно полноценно работать через минуту после запуска, и на работу не влияет ни сборка всего проекта в фоне, ни запуск тестов, ни checkout. И я совершенно не понимаю, какая разница, что оно работает наполовину на джаве. Работает же.
И, честно говоря, не думаю, что все легковесные загрузки и отложенные подгрузки расширений улучшат работу в студии до такого уровня.
Чего бы MS занимались оптимизацией загрузки R#? Тем более что R# нужен всегда и почти сразу, а Xamarin только тем, кто с ним работает. Так что это правильно, что они его загрузку оптимизируют. Мне, например, он совсем не нужен, а ресурсы отжирает.
a553
У меня достаточно противоположное вашему мнение насчет Rider. С моим проектом Rider гораздо нестабильнее, чем студия, постоянно что-то падает, подсказки уже традиционно не работают, подсветка кода сползает и т.п. Скорость загрузки солюшена немного отстает от голой VS без R#, а после визуальной загрузки подсветка кода ещё не работает минут пять (!).
В то же время в студии с решарпером кроме периодических подвисаний на полминуты решарпера, да тормозящих его же рефакторингов и других фич, никаких проблем с производительностью студии нет. Падает студия или анализатор раз в месяц-два.
Короче говоря, надежда пока есть, результата пока толком нет.
INC_R
Видимо, это сильно зависит от того, что разрабатывать. У меня это asp.net mvc 5.
Да, тоже постоянно в углу всплывают всякие ошибки, но чего-то фатального обычно не происходит. Бывает, что автодополнение подглючивает или подстветка, и действительно очень многое пока сыро. Но из двух зол я выбрал rider именно потому, что в нем все-таки продуктивнее работается. Лично мне проще, когда какая-то фича не работает (привыкаешь и не замечаешь), чем когда все работает правильно, но регулярно виснет на 3-10 секунд, даже когда ты просто пишешь код. Неимоверно раздражает.
ad1Dima
Почему-то все фанаты R# которые мне попадались, поголовно его хвалят, а на деле оказывается, что используют из него только статический анализатор и переименование переменных. Некоторые даже фичи студии приписывают R#. И эти же люди так же поголовно ругают студию за тормознутость. Видно маркетологи R# не зря свой хлеб едят.
ad1Dima
Если Java у вас в системе и так есть — никакой. Иначе — зачем ставить на машину дополнительную уязвимость — непонятно.
vba
Вы забыли про мин 7 гб для инсталляции студии в самом легковесном ее варианте? А тормоза при редактировании ХАМЛ? Я лучше джаву поставлю и райдер чем студию.
Я так же не вижу проблем ставить одну более меньшую уязвимость на черную дыру всех уязвимостей.
ad1Dima
Мы, кажется в статья про VS 15 которая весит 272 мб без всего https://www.visualstudio.com/news/releasenotes/vs15-relnotes#willow
Более меньшую? Винду ломают через трояны, которые пользователи запускают с правами админов, флеш и java.
Gorniv
Rider — это круто, особенно для мака, но пока Rider еще очень сырой, особенно для .net core.
Oxoron
С анализаторами пока туговато. А в плане навигации — все чаще и чаще я встречаюсь с повторами. Кстати, вопрос знатокам: можно ли отрубать R# функции по частям? Например, не просто скрыть подсказки на некоторые анализаторы, а полностью отключить некоторые виды анализа?
a553
Анализаторов в Visual Studio Gallery теперь полно.
mezastel
А вы пробовали, они годные? Есть ли где-нть дайджест того что есть, и насколько хорошо оно работает?
a553
Пробовал год назад. Тогда уже была вполне себе замена решарперу, кроме R# Build и, может быть, Test Runner-а. Актуального списка у меня сейчас нет.
mezastel
Я боюсь что "вполне себе замена решарперу" это позиция, которую вы в серьезной дискуссии не сможете защитить, ни с точки зрения количества фич, ни с точки зрения их качества :)
a553
Я боюсь, что вы намекаете на то, что фичи решарпера качественные.
fishca
есть смысл VS 2015 Community менять на VS «15» Preview 5?
easyman
В VS «15» Preview 5 нет .net core tooling
KindDragon
Нету еще VS «15» Community (только Enerprise), так что если у вас нет лицензии то ничего не получится
fishca
Спасибо, будем ждать VS «15» Community
worldxaker
так то для превьющек ключ не нужен
mazurkostya93
А лицензия от VS 2015 распространяется и на VS «15»?
KindDragon
Скорее всего
dimka11
т.е. «15» не поддерживает .net core?
Alex_ME
Ставил ее вчера. На середине установки попросила перезагрузиться, после перезагрузки открылось окно установщика с ошибкой, что установка %guid% не найдена.
Еще раз пытался, она зависла в конце установки библиотек. Сама студия поставилась, но ругалась на истекшую лицензию. Stack overflow советовал выполнить восстановление в «установке и удалении программ». Можно было только удалить, удаление упало.
Хотя 4.5Гб c# desktop + web + c++ против 13 у vs 2015 заманчиво.
Veikedo
Где-то уже был ответ почему они дали такое удобное название "15"?
staticlab
Это внутренний номер версии Студии.
slonopotamus
Внутренний номер 15.0. Это совсем не то же самое что «15» с кавычками.
dolbnya
Потому что это физически 15-ая версия. Visual Studio 2015, если взглянуть в Program Files будет располагаться в папке Microsoft Visual Studio 14.0
ad1Dima
До VS 2005 маркетинговое название студии шло в разнобой. В том числе была VS 6 которая была 6й.
С 2005 стали называть годом релиза (одного из двух на которые приходится финансовый год МС)
Сложность возникла когда в 2010 маркетинговое имя и номер года совпали. Для простоты в перзентациях и материалах VS2010 сокращалась до VS10, многие решили, что это просто сокращение года. но потом были VS2012(VS11), VS2013(VS12), тринадцатую версию они пропустили сразу VS2015(VS14), ну и теперь будет что-то вроде VS2016/17, а пока маркетологи до нее не добрались, просто VS15.
CaptainFlint
a553
На больших проектах libgit2 сильно тормозит, сам видел. Поэтому приходилось часто отключать Source Control в студии.
CaptainFlint
То есть сам Git работает нормально, а libgit2 тормозит? Это странно. Но тогда да, становится понятно, почему отказались.
KindDragon
К тому же гит это всегда отдельный процесс, а libgit по умолчанию работает синхронно и потребляет память в том же процессе.
CaptainFlint
Так это как раз и удобнее, что в рамках своего процесса вся работа идёт. Не надо парсить текстовый вывод, всё получаешь в готовом виде в переменных. Если проблема в подвисании, можно вынести в поток. Потребление памяти сильно отличаться не должно: в конце концов, новый процесс должен будет распарсить все те же данные, то есть съест столько же дополнительной памяти (и даже больше за счёт отдельного контекста и набора библиотек). Разве что защита от утечек, но решать её выносом в отдельный процесс — это даже не костыль, а я не знаю что. :-)
MacIn
Все верно, только проблема в том, что когда эта библиотека подвиснет, или поломает основной код Студии, все камни полетят в MS, мол, их продукция «как всегда, ну вы знаете(с)» кривая. Видимо, намного удобнее иметь отдельным процессом. В том же FF есть ведь plugin container для стороннего кода.
KindDragon
Еще студия 32-битный процесс, проблема с памятью острее.
excoder
Наверное убивают git.exe, это быстро — память структур удаляется скопом и не требует явной итерации для удаления. При работе с либой надо явно зачищать память, а это долго.
kekekeks
Он зато работает в отдельном процессе и ничего не завешивает.
MonkAlex
libgit2 реализовывал далеко не все фичи гита, так что правильный ход.
Может теперь то студия начнёт учитывать клиентские хуки.
Arxitektor
Вопрос по Visual Studio
При установке 2014 много пакетов качает из интернета.
На машине без него многое не поставить.
Можно ли как-то скачать все необходимое чтобы поставить на машине без интернета?
Kolay_Net
Да, Visual Studio поддерживает автономную установку. https://msdn.microsoft.com/ru-ru/library/e2h7fzkw.aspx
Необходимо запустить установочный файл с параметром
/layoutи установщик загрузит в указанную папку все файлы, кроме пакета SDK для Android, как указано по ссылке выше. Качал так неделю назад Visual Studio 2015 Professional, получилось в итоге 27 гигабайт на диске.Drakosvlad
Да, на странице загрузки можно выбрать загрузку .iso образа
NeoCode
Какие там требования? На семерку поставится еще?
MacIn
А Run to cursor в VS нет?
tangro
Есть. Речь только о новых иконках на строках — этого раньше не было.
13_beta2
А как же накладные расходы на сам процесс(ы) и IPC?
2016 год, а x64-версии на горизонте даже нет.
asdf87
Видимо, из двух зол выбираем меньшее. Когда память заканчивается еще хуже, чем задержки на IPC.
Плюс к этому, скорее всего в 1 момент времени активный IPC будет идти далеко не у всех плагинов одновременно, а только у нескольких, с которыми сейчас идет непосредственная работа.
По поводу 64-битной студии, похоже это уже несбыточная мечта. Там COM, там, говорят, в никоторых местах возвращаются 32-битные указатели в public API. Стойкое нежелание разработчиков VS это только подтверждает. Похоже, проще написать новую IDE аля Visual Studio Code, чем переписывать текущую. Так что в ближайшие 2-5 лет, по-моему ожидаются массовые миграции на Visual Studio Code и Rider
beavis88
Когда уже релиз будет?
StanGrin
Интересно когда будет релиз, хотя б примерно?
dmitry_dvm
Run to click очень нужная штука, скорее бы релиз.
А по поводу ускорения — у меня больше всего замедляет разработку uwp постоянные падения дизайнера со всякими мутными ошибками типа что-то там СОМ+. Вот реально почти при каждом переключении на вкладку с дизайнером падает. А еще очень бесит постоянное подчеркивание типа ошибок в стилях контролов.
3aicheg
Про каждую очередную версию студии пишут «мы стали более быстрее загружаться», но хоть бы раз правдой оказалось!
a553
Я поддерживаю несколько версий огромного проекта, они разрабатываются в разных студиях, начиная с 2008. Студии действительно стали быстрее загружаться.
3aicheg
В очень разных версиях огромной вселенной, похоже, мы с вами живём.
leremin
Лично я заметил огромное проседание в производительности IDE (vs 2015) во всех этих апдейтах: чем новее апдейт, тем студия больше тормозит, а начиная с Update 2 уже сотни раз видел сообщения, мол «для завершения операции не хватает памяти». Уже думал обратно стоковую ставить. Но вот начало этой статьи больно заманчиво звучит.
a553
Достаточно странная ситуация.
monah_tuk
Что JetBrains, что MS, посмотрите как сделан Locator в Qt Creator: не нужно помнить 100500 хоткеев, вызывается ровно одним: Ctrl-K (не суть, главное, что один), а дальше используется деление по префиксам — что хочешь искать:
.— методы и классы в текущем документе:— аналогично для проектаl— переход к строке (есть свой хоткей Ctrl-L, который делает подстановку в Локатор)git— пошли команды git плагинаи так далее. Дефолтный фильтр тоже настраивается: это тот фильтр, который будет работать если не будет введён префикс: просто отмечаются выводы каких фильтров туда попадают.
Да, в плане лёгкости расширения не самая удачная реализация, но как только привык, в других IDE уже как-то неудобно быстрой навигацией пользоваться.
a553
А зачем это вообще? Никогда не пользовался фильтрами в поиске; обычно всё, что мне нужно, показывается в первых нескольких результатах. Ваш вариант звучит очень неудобно.
Shultc
Человек же написал: Это нужно, чтобы не надо было запоминать кучу хоткеев! Теперь нужно запоминать только кучу префиксов…
monah_tuk
они перед глазами в виде подсказки при открытии:
KirillFormado
В VS Code как то так сделано, честно сказать, так и не понял удобно это или нет. Но кто знает, может это перейдет и в большую студия когда-нибудь.
PsyHaSTe
С тем же успехом можно кнопочками тыкать в интерфейсе. Хоткеи для того и нужны, чтобы их было много, но все они были доступны сразу, а не на 3-4 уровне вложенности меню.
TheShestov
Друзья, дЫк кнопка «ШЕДЕВР» уже появилась или еще пока подождать? :)
mezastel
Нужна такая кнопка "шедевр" которая еще и кастомное железо для вашей задачи проектирует.