Комментарии 69
У нас нет проблем с производительностью.Ну-ну
Ай-яй-яй. Вырвали из контекста фразу:
Про производительность их продукта был другой, вполне честный, ответ:
—У нас нет проблем с производительностью. У нас нет сомнений в том, что мы сможем в том же темпе писать новые анализы или еще более умные completion’ы и еще более умные рефакторинги.Тут не было речи о производительности их инструмента. Был лишь ответ о производительности их работы.
Про производительность их продукта был другой, вполне честный, ответ:
— К сожалению, да. Мы находимся в довольно тяжелом положении. У нас примерно половина багов с производительностью вызваны работой Visual Studio, а вторая половина — вызвана нами…
>Managed С++ — это абсолютно тупиковая ветвь развития технологий Microsoft, которая была призвана упростить интеграцию Managed кода с не-Managed кодом.
он сам в это верит?
>Я вижу, что сейчас большинство людей которым нужен interop, используют либо COM, либо Implicit PInvoke
com еще жив?
Implicit PInvoke если нужно вызвать метод или два, в случае если методов штук 10 — 20 в классах, гораздо удобней в C++/CLI обернуть и потом вызывать из c# как родного
> Совершенно верно. Я думаю, что Runtime отстает от JVM очень сильно. Виртуальная машина в .NET обладает очень плохим сборщиком мусора и очень слабым JIT-компилятором. В итоге получается медленно исполняющийся код.
студия 2013 или 2015 работают гораздо шутрее чем идея (24гига озу, ssd, corei5 2500k разогнан до 4.3), net работает быстрее как на десктопе (wpf) так и на серваке asp.net mvc.
давненько пробовал ReSharper, студия тоже начинает тормозить… наверное да виноват gc в net )
вообщем ни о чем
он сам в это верит?
>Я вижу, что сейчас большинство людей которым нужен interop, используют либо COM, либо Implicit PInvoke
com еще жив?
Implicit PInvoke если нужно вызвать метод или два, в случае если методов штук 10 — 20 в классах, гораздо удобней в C++/CLI обернуть и потом вызывать из c# как родного
> Совершенно верно. Я думаю, что Runtime отстает от JVM очень сильно. Виртуальная машина в .NET обладает очень плохим сборщиком мусора и очень слабым JIT-компилятором. В итоге получается медленно исполняющийся код.
студия 2013 или 2015 работают гораздо шутрее чем идея (24гига озу, ssd, corei5 2500k разогнан до 4.3), net работает быстрее как на десктопе (wpf) так и на серваке asp.net mvc.
давненько пробовал ReSharper, студия тоже начинает тормозить… наверное да виноват gc в net )
вообщем ни о чем
> студия 2013 или 2015 работают гораздо шутрее чем идея (24гига озу, ssd, corei5 2500k разогнан до 4.3), net работает быстрее как на десктопе (wpf) так и на серваке asp.net mvc.
Вот это высказывание «ни о чём», как Вы выразились. Сможете доказать?
Вот это высказывание «ни о чём», как Вы выразились. Сможете доказать?
ни о чем возможно слишком абстрактно, ощущения юзера при использовании без спец тестов.
в идее больше функционала сразу это да.
зависит от окружения задачи и тд… что тут доказывать
в идее больше функционала сразу это да.
зависит от окружения задачи и тд… что тут доказывать
Ну тогда я, как юзер, с Вами не соглашусь. Сейчас я, в основном, использую VS, но когда нужно что-то написать на Java, использую IDEA, и это как глоток свежего воздуха — всё буквально летает. Ваше субъективное восприятие против моего — это я и называю «ни о чём». Нужны объективные тесты производительности.
Про VS + R# — да, есть проблемы, о которых разработчики в JetBrains не скрывают. Но этому есть объективные причины, о которых и говорится в данном интервью. Roslyn построен на immutable-структурах данных, которые дают огромный memory footprint, с которым GC не справляется. В проекте, над которым я сейчас работаю (UI, WPF), stop-the-world GC, порой, работает больше, чем 4 секунды, из-за чего сервер теряет хартбиты, а трейдеры — ордера на сотни тысяч долларов. Из-за этого мы тратим огромное количество времени на оптимизацию расхода памяти. В Java я ни разу не видел FullGC больше секунды.
Про VS + R# — да, есть проблемы, о которых разработчики в JetBrains не скрывают. Но этому есть объективные причины, о которых и говорится в данном интервью. Roslyn построен на immutable-структурах данных, которые дают огромный memory footprint, с которым GC не справляется. В проекте, над которым я сейчас работаю (UI, WPF), stop-the-world GC, порой, работает больше, чем 4 секунды, из-за чего сервер теряет хартбиты, а трейдеры — ордера на сотни тысяч долларов. Из-за этого мы тратим огромное количество времени на оптимизацию расхода памяти. В Java я ни разу не видел FullGC больше секунды.
Если так сложно, зачем на .NET?
На сегодняшний день WPF — де-факто наиболее популярная технология для UI в свере банкинга. Я не могу сказать, хорошо это или плохо, но так оно есть, и не мне менять правила. А что бы Вы предложили взамен?
Хорошо что WPF популярен. Другое я не могу посоветовать, не проектировщик, но нагуглил что UI для трейдеров пишут на чем душе угодно.
Наверняка уже собрали или в ближайшем будущем соберете все лучшие техники оптимизации в одном месте.
Интересно почитать о том как Вы справились с этими проблемами на практике.
Наверняка уже собрали или в ближайшем будущем соберете все лучшие техники оптимизации в одном месте.
Интересно почитать о том как Вы справились с этими проблемами на практике.
Если с самого начала при построении архитектуры грамотно продумать менеджмент памяти, таких проблем не возникает. Но проект старый, и в нём есть множество наслоений функционала, поэтому и возникают подобные проблемы с GC. Универсального решения, увы, нет. Надо профилировать и находить узкие места.
В моём конкретном случае зависание приложения больше чем на 2 секунды было критичным. Мы потратили уйму времени на профилирование и оптимизации, но в результате пришли к выводу, что проще искусственно ограничить возможности системы. Трейдеры хотят видеть на мониторе (вернее, на 5-10 мониторах) по 50 окон, в каждом из которых будет открыто по несколько сотен инструментов с данными, обновляющимися по 10 раз в секунду. Это, если и реализуемо, то на чистом Ассемблере.
Про будущее: как это ни странно, видел пару экспериментальных проектов, написанных под Awesomium (поделка, выросшая из Chromium), где за доступ к данным отвечает C#-код, а за отображение — чистый JS). Не знаю, может быть, и правда будущее за этим.
В моём конкретном случае зависание приложения больше чем на 2 секунды было критичным. Мы потратили уйму времени на профилирование и оптимизации, но в результате пришли к выводу, что проще искусственно ограничить возможности системы. Трейдеры хотят видеть на мониторе (вернее, на 5-10 мониторах) по 50 окон, в каждом из которых будет открыто по несколько сотен инструментов с данными, обновляющимися по 10 раз в секунду. Это, если и реализуемо, то на чистом Ассемблере.
Про будущее: как это ни странно, видел пару экспериментальных проектов, написанных под Awesomium (поделка, выросшая из Chromium), где за доступ к данным отвечает C#-код, а за отображение — чистый JS). Не знаю, может быть, и правда будущее за этим.
НЛО прилетело и опубликовало эту надпись здесь
Так и есть, конечно. Клиент — на C#, сервер — на Java с подтюненым GC. Клиент раз в секунду отправляет хартбиты, и при потере хотя бы двух хартбитов сервер отменяет все ордера — это специальная защита от зависших на рынке «ничейных» ордеров. Так вот, когда трейдер открывает тысячи инструментов, по каждому из которых тикает маркет-дата, нагрузка на UI такая, что GC иногда не справляется. Ещё раз уточню: да, наверно проблема в неправильной архитектуре и чрезмерном количестве аллокаций. Но то, что GC в .NET-е может стопить весь процесс на 4 секунды, — это неприятно.
Ну вот, Вы сами ниже подтверждаете, что
Вот эти две фразы выносят мой мозг:
WPF — де-факто наиболее популярная технология для UI в свере банкинга.
Ну вот, Вы сами ниже подтверждаете, что
у всех С# на клиенте
НЛО прилетело и опубликовало эту надпись здесь
Custom Value Types, которые аллоцируются на стеке.
Если в поле класса есть тип значения, он будет размещен в динамической памяти или на стеке? Если на стеке, и таких объектов у меня 1000, как оно работает?
The Truth About Value Types, By Eric Lippert
Перевод где то был уже на хабре.
Я не имею ввиду что это не правда, просто это не вся правда. Вам я полагаю это хорошо известно, но решили не уточнять в своем сообщении такие детали.
НЛО прилетело и опубликовало эту надпись здесь
Согласен. Липперт для меня навел на мысль что время жизни объекта, вот что важно.
По производительности .NET отличная книга "Оптимизация приложений на платформе .Net", и "Отладка приложений для Microsoft .NET и Microsoft Windows".
GC добро, избавляющий от массы ошибок, правильно подобрать рецепт не так просто. Надеюсь в ближайшем будущем NetNative изменит ситуацию, сначала в магазине, потом в Desktop приложениях.
По производительности .NET отличная книга "Оптимизация приложений на платформе .Net", и "Отладка приложений для Microsoft .NET и Microsoft Windows".
GC добро, избавляющий от массы ошибок, правильно подобрать рецепт не так просто. Надеюсь в ближайшем будущем NetNative изменит ситуацию, сначала в магазине, потом в Desktop приложениях.
То, что Java используется в гораздо большем количестве проектов, чем C#, это не означает, что она быстрее и лучше, просто на то были объективные причины. Сейчас все уже намного лучше.
Я сомневаюсь, что С# работает на сервере медленнее Java, даже если он работает на старом JIT, а не новом RyuJIT.
В .NET 4.5 новый фоновый сборщик мусора, с ним тоже все плохо?
Борьба со сборкой мусора напоминает проблемы с блокировками при многопоточности. Потом вдруг все осознали, что нужно использовать другие структуры данных и другие паттерны и дело пошло куда лучше.
Я сомневаюсь, что С# работает на сервере медленнее Java, даже если он работает на старом JIT, а не новом RyuJIT.
В .NET 4.5 новый фоновый сборщик мусора, с ним тоже все плохо?
Борьба со сборкой мусора напоминает проблемы с блокировками при многопоточности. Потом вдруг все осознали, что нужно использовать другие структуры данных и другие паттерны и дело пошло куда лучше.
В .NET 4.5 новый фоновый сборщик мусора, с ним тоже все плохо?
Не уверен, но похоже, эта часть комментария была адресована мне. Мы перепробовали все возможные настройки GC, которые только есть. Были даже попытки оценивать Memory Pressure и вручную вызывать GC заблаговременно, пока не стало совсем плохо. Ничего не помогало. Ситуацию спас банальный переход на x64 (ещё до RyuJIT). В x86, какой режим сборщика ни включай, всё-равно есть вероятность схватить stop-the-world сборку. Правда, в .NET 4.5 это действительно происходило реже.
>всё буквально летает.
странно такое слышать после того что я вижу у себя каждый день
>В проекте, над которым я сейчас работаю (UI, WPF), stop-the-world GC, порой, работает больше, чем 4 секунды…
это не показатель gc, а всего лишь данного приложения.
тестировался функционал без wpf? если это возможно
на java тоже был гуи на swing или подобном? и тд… примеры у каждого найдутся различных сценариев
странно такое слышать после того что я вижу у себя каждый день
>В проекте, над которым я сейчас работаю (UI, WPF), stop-the-world GC, порой, работает больше, чем 4 секунды…
это не показатель gc, а всего лишь данного приложения.
тестировался функционал без wpf? если это возможно
на java тоже был гуи на swing или подобном? и тд… примеры у каждого найдутся различных сценариев
Ой, всё просто — отключите ReSharper в Visual Studio — она вам покажется глотком свежего воздуха после IDEA.
Львиная доля функционала resharper либо уже втащена нативно в VS 2015 либо реализуется точечными экстеншнами. Которые быстры именно за счёт неперегруженности.
Сам же resharper это долбанный комбайн, который ещё надо мучительно резать, отрубая ненужныесвистоперделки низкоприоритетные и малоиспользуемые функции, чтоб получить только тот функционал, который нужен. И в этот момент понимаешь, что resharper-то не нужен!
Львиная доля функционала resharper либо уже втащена нативно в VS 2015 либо реализуется точечными экстеншнами. Которые быстры именно за счёт неперегруженности.
Сам же resharper это долбанный комбайн, который ещё надо мучительно резать, отрубая ненужные
студия 2013 или 2015 работают гораздо шутрее чем идея (24гига озу, ssd, corei5 2500k разогнан до 4.3)
Сравните количество предлагаемых фич по работе с кодом в IDEA и в VS. В VS15 фич стало больше, чем ноль, но это далеко не та же функциональность. Естественно за неё нужно платить производительностью.
Честно говоря, скучно слушать подобных менеджеров. Сплошное лицемерие и проталкивание корпоративной визийной бессмыслицы.
Например, по поводу подписок. Снова что-то выдумывается в оправдание, типа белое — это, по-сути, чёрное, только наоборот. Хвалятся вышестоящие и придумываются заслуги. Вместо того, чтобы просто признать, что хотелось больше денег.
Интересно слушать людей, которые реально что-то делают.
Например, по поводу подписок. Снова что-то выдумывается в оправдание, типа белое — это, по-сути, чёрное, только наоборот. Хвалятся вышестоящие и придумываются заслуги. Вместо того, чтобы просто признать, что хотелось больше денег.
Интересно слушать людей, которые реально что-то делают.
А мне наоборот понравилось. Если не вдаваться в финансовый вопрос (Мне не особо интересно кто хочет бабла, а кто не хочет. Все хотят.), видно, что менеджмент в JetBrains весьма компетентен в технической части.
По поводу людей, которые что-то делают — не совсем понял. Вы считаете, что программисты, которые написали R#, делают больше, чем руководитель отдела разработки?
По поводу людей, которые что-то делают — не совсем понял. Вы считаете, что программисты, которые написали R#, делают больше, чем руководитель отдела разработки?
Этот, как вы выражаетесь, «менеджер» даст нам всем фору в плане кодинга сто очков вперед — будьте уверены!
Про подписки — вопрос уже оскомину набил. Но все-таки,
Снова что-то выдумывается в оправданиене похожи ответы ни на «оправдание», ни на «выдумывается» (все уже давно выдумано).
Хвалятся вышестоящие и придумываются заслугиРебята из JetBrains частенько хвалятся не только вышестоящими, но и собой, своей командой, и своими продуктами (не без оснований). Насчет придумывания — вопрос сильно холиварный.
Честно говоря, скучно слушать подобных менеджеров…Послушайте Сергея на dotNext, очень даже познавательно.
Интересно слушать людей, которые реально что-то делают.
а когда dotTrace/dotPeek начнёт понимать async/await?
А не могли бы пояснить, что значит «понимать async/await»?
Думаю, вот что это значит.
Пока эта фича пока не запланирована на следующую версию. Более долгосрочный планов мы не делаем. Внутри команды мы много раз обсуждали что нужно сделать для того чтобы анализировать async было проще, но в конкретные фичи ничего пока не превратилось. Пользуясь случаем, могу я попросить вас описать задачи которые хотелось бы решать? (какой-нибудь типичный баг в асинхронном коде которые не видно просто в dotTrace timeline) Если какая-то проддержка будет, то скорее всего только в режиме профиляции Timeline.
Вот мне что интересно:
Я никоим образом не пытаюсь сказать, что ReSharper плохой продукт. Он многим нравится и без него как без рук. Порой действительно трудно понять, то ли это студия тормозит, то ли стоит… отключить еще что-нибудь.
Взываю к mezastel и другим сотрудникам, чтобы прояснили ситуацию :)
- Был freeze UI при сохранении XAML в VS 2015. Так я в гугле не нашел, у кого бы проявлялась такая проблема. А проявлялась она у всех наших сотрудников. В update 1 вроде бы починили, но все равно бывает проскакивает это зависание. Это проявлялось без решарпера, но с ним всё только усугублялось. Мы одни такие или это общая проблема? Можно как-то решить?
- С точки зрения UI freeze очень сильно напрягает окошко тестирования. К примеру, у меня есть 500+ разных тестов. Как только пытаешься их прогнать перед отправкой кода на сервер — видно, как решарпер упирается в количество тестов и обновление их результатов занимает время примерно N^2, где N — количество тестов (т.е. не 500^2 секунд, а субъективное ощущение, что зависания UI увеличиваются в N^2 раз в зависимости от числа тестов). Именно обновление UI тестов. Я знаю, что вы используете компоненты DevExpress. Может вам стоит переписать часть контролов с использованием WriteableBitmap(Ex)? Мне кажется, что это могло бы избавить вас от лишних задержек.
- В офисах JetBrains раздают бесплатные мандаринки к Новому Году?
Я никоим образом не пытаюсь сказать, что ReSharper плохой продукт. Он многим нравится и без него как без рук. Порой действительно трудно понять, то ли это студия тормозит, то ли стоит… отключить еще что-нибудь.
Взываю к mezastel и другим сотрудникам, чтобы прояснили ситуацию :)
На сколько я понимаю, freeze UI происходит из-за перекомпиляции xaml-файлов во всём солюшне на каждый чих, даже при переключении между табами. Это нужно для корректной работы IntelliSense. Если проект большой, VS будет тормозить. Вроде бы, когда-то давно на коннекте был заведен баг, и его обещали пофиксить, но не помню в какой версии. В последнее время я с ним не сталкивался.
1. UI freeze во время сохранения XAML как написал товарищ lam0x86 не только у вас, наверное у всех кто пишет большое WPF приложение с кучей xaml файлов. Я сам от этой проблемы страдаю. Избавиться помогает только распиливание солюшена на более мелкие. С решарпером усугубляется может потому, что свободной памяти в 32-битном процессе становится еще меньше и GC возникает чаще.
2. В окошке UT свой контрол, DevExpress там нет. Контрол в 10 версии был переписан и сейчас как раз ведутся работы по сглаживанию острых углов и улучшению производительности.
3. Конечно, каждый день! И не только к Новому Году.
Я программист из dotTrace.
2. В окошке UT свой контрол, DevExpress там нет. Контрол в 10 версии был переписан и сейчас как раз ведутся работы по сглаживанию острых углов и улучшению производительности.
3. Конечно, каждый день! И не только к Новому Году.
Я программист из dotTrace.
Спасибо, все очень актуально.
1. Баг есть, при сохранении xaml файлов студийный Language Service для xaml вызывает перекомпиляцию. Это действительно нужно для работы VS IntelliSense, так как из xaml можно использовать C# код и наоборот, компиляция происходит сложно, в два прохода. Но сами тормоза обусловлены тем, что при недостатке памяти MsBuild, который работает in-process в devenv.exe, пытается освободить память путем сериализации на диск 10% из своих внутренних структур данный. И проверяет результат, вызывая GC 2. По тем же причинам может втыкать добавление и удаление файлов или ссылок в проектах.
Из рекомендаций — переключить дефолтный редактор на source code editor (вместо xaml editor), перенести общие контролы (использующиеся в xaml в другой проект чтобы избежать 2-стадийной компиляции). Уменьшать количество проектов (если это возможно) для экономии памяти. Отключать фичи решарпера которыми Вы не пользуетесь в окошке опций.
2. В 10.0.2 нет DevExpress уже. Пожалуйста, присылайте профили если что-то все еще тормозит.
1. Баг есть, при сохранении xaml файлов студийный Language Service для xaml вызывает перекомпиляцию. Это действительно нужно для работы VS IntelliSense, так как из xaml можно использовать C# код и наоборот, компиляция происходит сложно, в два прохода. Но сами тормоза обусловлены тем, что при недостатке памяти MsBuild, который работает in-process в devenv.exe, пытается освободить память путем сериализации на диск 10% из своих внутренних структур данный. И проверяет результат, вызывая GC 2. По тем же причинам может втыкать добавление и удаление файлов или ссылок в проектах.
Из рекомендаций — переключить дефолтный редактор на source code editor (вместо xaml editor), перенести общие контролы (использующиеся в xaml в другой проект чтобы избежать 2-стадийной компиляции). Уменьшать количество проектов (если это возможно) для экономии памяти. Отключать фичи решарпера которыми Вы не пользуетесь в окошке опций.
2. В 10.0.2 нет DevExpress уже. Пожалуйста, присылайте профили если что-то все еще тормозит.
Почему-то про проблемы Java (зачастую мнимые) знают даже те, кто не пишут на нем, не говоря о том, что в самом сообществе практически только это и обсуждается (сборка мусора, темп развития, легаси технологии, страхи и ужасы энтерпрайза..) А .Net (со стороны) представляется как что-то более, что ли, «правильно сделанное», но по чисто историческим причинам не такое популярное, как Java. А там вон сколько проблем.
Общее мнение, которое складывается после четырех DotNext — с языком все довольно хорошо, а с рантаймом все довольно плохо.
Во-первых, хочу поблагодарить за отличное интервью, лично мне оно показалось очень содержательным. Во- вторых у меня возникла пара вопросов:
1. Возможно вы или Сергей знаете или предполагаете, почему МС почти не вкладывается в рантайм? Ведь казалось бы, рантайм джавы открыт, бери и перенимай лучшие практики и если у тебя есть достаточный бюджет и умные люди, то твой рантайм должен быть как минимум не хуже.
2. Насколько я понял Сергей технарь до мозга костей и плюс еще тех менеджер, но я не совсем понял, могут ли тех менеджеры в JetBrains влиять на политику компании в отношении лицензий? Или этим вопросом занимаются люди из отдела продаж?
1. Возможно вы или Сергей знаете или предполагаете, почему МС почти не вкладывается в рантайм? Ведь казалось бы, рантайм джавы открыт, бери и перенимай лучшие практики и если у тебя есть достаточный бюджет и умные люди, то твой рантайм должен быть как минимум не хуже.
2. Насколько я понял Сергей технарь до мозга костей и плюс еще тех менеджер, но я не совсем понял, могут ли тех менеджеры в JetBrains влиять на политику компании в отношении лицензий? Или этим вопросом занимаются люди из отдела продаж?
Microsoft в последнее время вместо runtime'а очень сильно вложились в собственно компилятор, досконально его переписав. Это титаническая работа. На это время было много чего приостановлено, в т.ч. радикальные фичи C# (вспомним релиз C#5). Помимо этого, Microsoft начали писать новый Jitter (RyuJIT), который призван улучшить производительность, например с использованием JIT.
Также, не будем забывать, что в «кухне» МС очень много других около-.NET технологий связанных с различными фреймворками (WP8, Windows Store, etc.) который тоже забирают много ресурсов, а также новые релизы вроде Core CLR. Вот и имеем, в результате, ситуацию в которой все уже чем-то заняты и на основной runtime не осталось ресурсов.
Также, не будем забывать, что в «кухне» МС очень много других около-.NET технологий связанных с различными фреймворками (WP8, Windows Store, etc.) который тоже забирают много ресурсов, а также новые релизы вроде Core CLR. Вот и имеем, в результате, ситуацию в которой все уже чем-то заняты и на основной runtime не осталось ресурсов.
Команды разработки Майкрософт постоянно активно просят сообщество делиться своим мнением, найденными ошибками, предложениями по улучшению и тп. И насколько я наблюдаю, они этот фидбек учитывают при планировании дальнейшей разработки своих продуктов. Так что если что-то не нравится, есть мысли как сделать правильно, или есть какая-то досадная ошибка, которая мешает вам жить — имеет смысл воспользоваться системой Microsoft Connect, в частности для Visual Studio это connect.microsoft.com/VisualStudio/Feedback Там можно как просто проголосовать за имеющиеся тикеты, так и добавить новый.
1. Совершенно согласен, просят. Активно.
2. При планировании новых продуктов действительно учитывают и принимают баги в развивающихся продуктах.
3. Проблема в том, что есть продукты уже развившиеся и есть направления, которые находятся вне фокуса, в режиме поддержки. Приведу пример проблем в VS 2010-2015 которые не являются приоритетными и не исправляются:
— перезагрузка проектов после изменения проектных файлов. так квадратичная зависимость от количества проектов. в более или менее больших солюшенах единственный способ обновится из vcs — перезапуск студии.
— DirectoryWatcher. при билде он не дает ничего делать, так как заничет UI поток обработкой изменения на диске. Там проблема стандартная в том, что переполняется кэш File system watcher-а и происходит обход большого поддерева файловой системы полностью. (сейчас — в 2015 upsate 1, добавились memory leaks: twitter.com/serjic/status/670190879089520641)
— запуск MsBuild при редактировании проекта (добавление файлов или ссылок) может вызвать паузы в искусственно вызванном GC в десятки секунд.
— уже упомянутое здесь редактирование xaml файлов.
— сейчас добавились многочисленные проблемы с производительностью roslyn.
— и еще безумно много мелких проблем…
Я соглашусь, что баги есть у всех. Да, VS — качественный продукт. Там мало фич, но то что есть сделано качественно. Это качество дается не бесплатно, мой опыт показывает что добиться исправлений или улучшений в некоторых областях невозможно.
2. При планировании новых продуктов действительно учитывают и принимают баги в развивающихся продуктах.
3. Проблема в том, что есть продукты уже развившиеся и есть направления, которые находятся вне фокуса, в режиме поддержки. Приведу пример проблем в VS 2010-2015 которые не являются приоритетными и не исправляются:
— перезагрузка проектов после изменения проектных файлов. так квадратичная зависимость от количества проектов. в более или менее больших солюшенах единственный способ обновится из vcs — перезапуск студии.
— DirectoryWatcher. при билде он не дает ничего делать, так как заничет UI поток обработкой изменения на диске. Там проблема стандартная в том, что переполняется кэш File system watcher-а и происходит обход большого поддерева файловой системы полностью. (сейчас — в 2015 upsate 1, добавились memory leaks: twitter.com/serjic/status/670190879089520641)
— запуск MsBuild при редактировании проекта (добавление файлов или ссылок) может вызвать паузы в искусственно вызванном GC в десятки секунд.
— уже упомянутое здесь редактирование xaml файлов.
— сейчас добавились многочисленные проблемы с производительностью roslyn.
— и еще безумно много мелких проблем…
Я соглашусь, что баги есть у всех. Да, VS — качественный продукт. Там мало фич, но то что есть сделано качественно. Это качество дается не бесплатно, мой опыт показывает что добиться исправлений или улучшений в некоторых областях невозможно.
Ну так запостить проблему и организовать мощный флэшмоб с целью сбора голосов за исправление бага — дело нехитрое.
Вот кого бесят тормоза XAML — проголосуйте по разу, добавьте свой фидбек. Или переоткройте эти тикеты, или найдите подобные и переоткройте, или создайте новые. В общем чтобы что-то поменялось, надо что-то предпринять. :)
Вот кого бесят тормоза XAML — проголосуйте по разу, добавьте свой фидбек. Или переоткройте эти тикеты, или найдите подобные и переоткройте, или создайте новые. В общем чтобы что-то поменялось, надо что-то предпринять. :)
Большинство из вышеперечисленного я лично (при личных встречах) озвучивал разработчикам и менеджерам из соответствующих команд. И мы соглашались с тем, что это важные баги. Не знаю, что я могу еще сделать? То есть что я могу сделать я знаю и делаю, мы находим пути как обойти отсутствующие точки расширения, заткнуть мешающую функциональность и перекрыть фичи, которые не предназначены для того чтобы их перекрывать. Приведу пример: для того чтобы FTS понимал что мы программно перемещаем файл, мы в нашем коде эмулируем drag-and-grop в solution explorer. чтобы делать рефакторинги и темплэйты в xaml файлах мы при опять же программном изменении тэгов боремся с фичей студии по синхронному редактированию тэгов. Сколько людей поддержат реквест про то что какой-то API не выдает события в каких-то случаях? У нас такие проблемы возникают каждую неделю. И для нас это business critical. И пользователи ждут что все заработает сразу после выхода очередной версии студии. Добиться разъяснений сложно, добиться изменений невозможно.
Да, я тоже возился с TFS. По поводу VSX — пишите прямо в команду VSX Team — поройтесь в авторах (блог правда обединился с Visual Studio давно). Можно полистать посты тут и связаться с авторами — их несложно найти в соцсетях или связаться через коментарии к постам. Разумеется приходится срочные моменты рещать самостоятельно. Но это уже другая история :)
Roslyn — может и сырая, но крайне любопытная технология с точки зрения создания разнообразных расширений Visual Studio — и всяких помогалок вроде ReSharper и других. Сырая — лучше чем отсуствие какой-либо и работа с COM архитектурой IDE.
Проблема со всякими нагружающими бекграунд-процессами решается их отключением, если они не нужны. Тут я проблемы не вижу.
Проблема со всякими нагружающими бекграунд-процессами решается их отключением, если они не нужны. Тут я проблемы не вижу.
Не подскажите, как выключить полностью бэкграунд-анализ солюшена Roslyn'ом, а также компиляцию xaml в бекграунде в VS2015 Update 1? Меня в высшей степени раздражают дикие тормоза по 2-5 минут на простых операциях — вроде навигации по файлам, а также изредка случающиеся зависания длительностью в несколько часов при билде или отладке. А когда в такой момент профилируешь студию и видишь что-нибудь вроде SimplifyNameDiagnostics — то трудно сдерживать негативные эмоции в себе.
Архитектура Visual Studio прекрасна, когда поймешь ее суть. Все собирается в кучу на основе конфигурации хранящейся в реестре.
В VS2013 была галочка «Show live semantic errors» которую можно было отключить. В VS2015 с интерфейса ее убрали.
Поэтому:
Можеет тут поковыряться в прочих настройках. Включать и выключать их можно аналогично.
В VS2013 была галочка «Show live semantic errors» которую можно было отключить. В VS2015 с интерфейса ее убрали.
Поэтому:
- Идем в реестр, находим (или создаем если нету) ключ HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\14.0\Roslyn\Internal\OnOff\Features
- Прописываем значение Squiggles типа DWORD и ставим для него 0 чтобы выключить. Ну 1 чтобы включить сответственно.
- Перезапускаем студию (убедиться что в процессах devenv действительно выгрузился перед повторным запуском студии)
Можеет тут поковыряться в прочих настройках. Включать и выключать их можно аналогично.
этой настройкой мы даже пользовались до 10.0 для отключения студийной подсветки. К сожалению Language service обслуживает еще очень много фич в VS начиная с IntelliSense и заканчивая диаграммами, дебаггером итд. То есть, отключая отдельные фичи, мы не остановим Roslyn, не заставим его потреблять меньше памяти. Ну или что-то отломаем для пользователей. Из действенного есть галочка в опциях (что-то типа analyze files opened in editor) — она заставляет студию не анализировать файлы которые не открыты в редакторе с целью показать там ошибки в errors view.
да минусы, разумеется, есть. честно говоря, интеллисенс, когда он заставляет ждать, скорей раздражает, чем помогает. при повседневной работе с XML-подобными исходниками, достаточно просто подсветки разметки, поэтому достаточно (субъективно, разумеется) выбрать в качестве редактора по умолчанию максимально простой из имеющихся. студия и ее возможности плохо задокументированы (по крайней мере так было несколько лет назад, когда я активно работал с VSSDK, MPF и ядром автоматизации на базе макросов), о многом приходилось догадываться самому :) но в целом — отключить и включить можно было так или иначе почти все. в ближайшее время попробую эту область опять — интересно даже — многое ли изменилось.
Вот бы подобные настройки были документированы с возможностью настройки для солюшена, со включением в репозиторий…
Напишите плагин с студии, который добавляет новый Options Page для узла Text Editor — General — есть даже пример как добавить свой собственный узелю Вам понадобится для общего Text Editor узла из рееста найти и использовать его GUID-ы просто. В логике напишете управление ключами рееста. На UI сможете переключать галочки :) Думаю сложностей большых возникнуть не должно. Встроить в имеющие табики галочку конечно не выйдет, но думаю это не проблема — отдельный таб — вполне нормально.
Про XAML — есть парочка советов как себе немного облегчить ежедневную боль.
Сильно удивился, узнав, что .Net медленнее джавы…
Ощущение, что это очень, такая, рекламная статья, обернутая в форму интервью.
Скажите, а EAP в решарпере будет?
Почему dotPeek такой тормозной? Невозможно им пользоваться. Даже просто запуск происходит около минуты.
При всём уважении к JetBrains вместо того, чтобы заниматься бесполезным развитием решарпера, лучше бы они бросили всю команду на более полезные вещи. Например поддержку C# в Idea.
Есть вот такой анонс:
blog.jetbrains.com/dotnet/2016/01/13/project-rider-a-csharp-ide
blog.jetbrains.com/dotnet/2016/01/13/project-rider-a-csharp-ide
декабрь 2015
январь 2016
blog.jetbrains.com/dotnet/2016/01/13/project-rider-a-csharp-ide
Как-то некрасиво получилось…
Остальному сказанному, видимо, стоит так же доверять.
— Насколько имеет смысл вообще заниматься всей возней c Visual Studio, учитывая, что у вас в компании офигенный опыт и очень успешный спрос по построению собственных IDE?
— Visual Studio, конечно, имеет смысл, с нее мы никуда не слезем. Это инструмент, который обеспечивает разработку на всех платформах, которые нужны для Microsoft. Он меняется раз в три месяца и поддерживает новые платформы от Microsoft. Повторять эту работу — вовсе не наш приоритет.
В первую очередь нужно понимать, что Visual Studio решает внутренние задачи Microsoft. Вот, например, вышла Universal Windows Platform, а под нее нужно все программы дебажить, запускать, профилировать, настраивать проекты, которые будут работать под разные платформы… Это мы повторять не будем.
январь 2016
blog.jetbrains.com/dotnet/2016/01/13/project-rider-a-csharp-ide
Today, at NDC London, we announced a new project that we’ve been working on for a little while – a cross-platform C# IDE, based on the IntelliJ Platform and using ReSharper technology.
Как-то некрасиво получилось…
Остальному сказанному, видимо, стоит так же доверять.
А никто и не повторяет — текстовый редактор в IJ был, а поддержку UWP, например, никто особо делать не собирается. ;)
1. Релиз этот — последовательное развитие логики «С Visual Studio трудно работать», которая прослеживается и в этом интервью и в интервью Дмирия Нестерука.
2. Такие вещи не раскрываются заранее по многим соображениям — коммерческим, политическим. Или банально из-за отсутствие финального решения на момент интервью.
Оба этих момента кажутся мне настолько очевидными, что я даже не знаю, стоит ли на них останавливаться.
Вы намекаете, что вас обманули. Я бы скорее заходил с другой стороны — привлекли ваше внимание к проблеме, объяснили эту проблему и, три недели спустя, дали решение. Большего и требовать сложно.
2. Такие вещи не раскрываются заранее по многим соображениям — коммерческим, политическим. Или банально из-за отсутствие финального решения на момент интервью.
Оба этих момента кажутся мне настолько очевидными, что я даже не знаю, стоит ли на них останавливаться.
Вы намекаете, что вас обманули. Я бы скорее заходил с другой стороны — привлекли ваше внимание к проблеме, объяснили эту проблему и, три недели спустя, дали решение. Большего и требовать сложно.
Я ни на что не намекаю, я говорю, что говорить одно, а делать другое, некрасиво. Даже если вещь хорошая (коей безусловно будет являться новая IDE от JB).
> Такие вещи не раскрываются заранее по многим соображениям
Тогда бы оно звучало как-то так:
— Насколько имеет смысл вообще заниматься всей возней c Visual Studio, учитывая, что у вас в компании офигенный опыт и очень успешный спрос по построению собственных IDE?
Конечно, имеет смысл, с нее мы никуда не слезем.
Что касается отдельной IDE, то мы думали и продолжаем думать о этом, но решения по этому вопросу нет.
> Такие вещи не раскрываются заранее по многим соображениям
Тогда бы оно звучало как-то так:
— Насколько имеет смысл вообще заниматься всей возней c Visual Studio, учитывая, что у вас в компании офигенный опыт и очень успешный спрос по построению собственных IDE?
Конечно, имеет смысл, с нее мы никуда не слезем.
Что касается отдельной IDE, то мы думали и продолжаем думать о этом, но решения по этому вопросу нет.
Так они вроде и не писали, что не делают, просто написали, что это не является приоритетным направлением для них — это все-таки разные вещи.
Они не говорили что не будут писать свою IDE. Они говорили, что не будут слезать с вижуал студии, так как там куча всякого для поддержки технологий MS. То есть для того, чтобы противоречить своим словам им надо было прекратить поддержку VS а не начать поддерживать не-VS.
Насколько я понял новая IDE нужна для поддержки той части микрософтовского стека, которая кроссплатформенна (фактически сам язык, может Katana) — всякие там WPF и UWP не поддерживаются и, судя по интервью, не планируются. (В противном случае им пришлось бы безжать на перегонки с о студией а не сидеть на ней сверзху в этом вопросе).
Сейчас скорее всего он конкурируют с VS code в каком-то смысле.
Интересно также зачем им отдельная IDE а не Resharper-for-IDEA (наверное маркетинг?)
Насколько я понял новая IDE нужна для поддержки той части микрософтовского стека, которая кроссплатформенна (фактически сам язык, может Katana) — всякие там WPF и UWP не поддерживаются и, судя по интервью, не планируются. (В противном случае им пришлось бы безжать на перегонки с о студией а не сидеть на ней сверзху в этом вопросе).
Сейчас скорее всего он конкурируют с VS code в каком-то смысле.
Интересно также зачем им отдельная IDE а не Resharper-for-IDEA (наверное маркетинг?)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
«Roslyn — еще очень сырая технология» — интервью с Сергеем Шкредовым, руководителем .NET-направления в JetBrains