«Хаос в .NET-мире — разумная цена за скорость развития платформы»: интервью с Андреем Акиньшиным (JetBrains)



    Проект Rider (.NET IDE от JetBrains) дошёл до публичной EAP-версии — самое время подробно расспросить Андрея Акиньшина, одного из его разработчиков. Но Rider стал не единственной темой нового выпуска «Без слайдов». Помимо него, поговорили:

    • о библиотеке BenchmarkDotNet, которую разрабатывает Андрей
    • о движении Microsoft к опенсорсу и кроссплатформенности
    • об общем состоянии .NET-мира и, конечно,
    • о .NET-конференции DotNext (которая, кстати, состоится в Москве уже в эту пятницу)

    Как всегда, под катом есть полная расшифровка интервью.



    Rider


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

    — У нас как команды ощущения очень хорошие: мы все сидим на Rider, 90% времени пишем в нём. Мы самые старые пользователи Rider, потому что стали его использовать ещё с самых первых версий, когда можно стало хоть что-нибудь в нём писать.

    Нам всем очень нравится, Rider — это очень клёвая IDE, и главным образом из-за того, что мы девелопим отчасти для себя. То есть все вещи, которые неудобны, раздражают или нельзя сделать, замечает вся команда, мы все страдаем от этих вещей каждый день. Спустя какое-то время у кого-то чешутся руки, он идёт и просто правит эту функциональность. Также Rider основан на кодовой базе ReSharper и IntelliJ IDEA, а это очень клёвые продукты, каждый из которых разрабатывается больше 10 лет, в каждом очень много фич, каждый очень сильно оптимизирован. В Rider ещё не всё готово, но то, что готово, работает очень хорошо, и нам очень нравится этим пользоваться.

    — ReSharper работает с Visual Studio внутри процесса, или в отдельном процессе?

    — Он работает внутри процесса, и это большая проблема, потому что год 2016-й, а Visual Studio — всё ещё 32-битный процесс, и многие наши пользователи жалуются, что ReSharper тормозит. ReSharper не тормозит, он работает как раньше и даже быстрее, но Студия с каждой новой версией потребляет всё больше памяти, и нам в рамках этого 32-битного процесса становится всё теснее. И в плане тормозов Rider — живое этому доказательство: мы вылезли из процесса Студии, и всё летает.

    — А почему было не сделать ReSharper out of process?

    — Это очень сложно, во-первых, в плане интеропа с самой Студией, а во-вторых… В Rider мы, по сути, реализовывали интероп между IDEA и ReSharper. Сделали мы это с помощью своего кастомного протокола, который мы очень долго разрабатывали, очень много тюнили.

    Прекрасная работа сделана, очень удобно пользоваться, очень быстро всё работает, но всё равно есть какие-то проблемы, есть вещи, которые не продуманы, неудобно сделаны. И даже связать два продукта, каждый из которых делаем мы сами, в каждом из которых мы можем что угодно поменять — это уже очень непростая, сложная техническая задача. Со Студией крайне сложно было бы такое реализовать.

    — А если чуть по-другому зайти: вот сейчас вы уже отработали для Rider out-of-process режим, и протокол у вас есть. Вот если пофантазировать: это возможно всё интегрировать в Студию, или придётся всё переделывать?

    — Ну, чисто технологически — да, можно, иногда мы даже думаем про это. Но нужно понимать, что это очень большая и сложная задача. Если мы этим когда-нибудь будем заниматься, то нужно очень хорошо понимать, что это рентабельно, и тот объём труда, который мы в это вложим, себя в конечном счёте оправдает.

    — Ну вот есть тренд, что Visual Studio потребляет всё больше и больше памяти. Предпосылок, что будет потреблять меньше, нет, и возникает вопрос, для чего там останется место.

    — Ну, никто не знает, что будет с Visual Studio завтра, поэтому мы пока на ней сидим. Всё, что я могу сказать: cегодня таких планов нет (на самом деле есть, ребята из ReSharper об этом в открытую говорят — прим. авт.). Сегодня мы активно пилим Rider, это наш главный приоритет.

    — Что вам пишут пользователи? У вас уже была закрытая early access-программа, я её участник и даже репортил вам баги — могу сказать, что я вообще early adopter. Много ли было пользователей у закрытого EAP?

    — Да. Думаю, людей, которые активно разрабатывают в Rider, тысячи. Фидбэк колоссальный и очень хороший.

    — «Хороший» в смысле «позитивный», или в смысле «пищу даёт»?

    — И позитивный, и конструктивный. Early Access Program (EAP) позволила нам выявить на ранних этапах разработки вещи, которые мы не проработали.

    — Приведи примеры?

    — Например, поддержка Unity или Xamarin. Очень многие люди пытаются использовать Rider для этих целей, и их фидбэк был очень ценен для нас. Мы сами им каждый день пользуемся, но вот Unity или Xamarin — это не те технологии, на которых вся команда ReSharper девелопит каждый день. И мы в некоторых моментах не до конца понимаем, что нужно пользователям, чего им в этой жизни не хватает, что в текущем инструментарии их не устраивает. В этом отношении фидбэк очень ценен.

    Иногда приходят просто багрепорты, что «мы сделали вот так, и у нас всё сломалось». Или приходят фича реквесты: было бы здорово, если бы была такая-то функциональность. Мы всё это слушаем, общаемся с людьми, стараемся оперативно, насколько это возможно, реализовывать.

    — Сколько вас сейчас работает над Rider?

    — Core Team — чуть больше 10 человек, но нужно понимать, что ещё у нас есть команды ReSharper и IDEA, с которыми мы тоже постоянно сотрудничаем. Иногда находим баги в той или иной платформе, иногда нам не хватает какого-то функционала, мы приходим к ребятам из других команд, и как-то обсуждаем эти проблемы. Поэтому можно сказать, что за сотню.

    — В «Без слайдов» в своё время Дима Жемеров рассказывал про то, как IDEA превратилась из IDE в платформу через механизм Extension Points. А Сергей Шкредов рассказывал, что ReSharper умеет, условно, прогонять инспекции в nightly-билдах, всё это провязывается с TeamCity, и так далее. Правильно ли я понимаю, что примерно в этих двух местах и была сделана интеграция? То есть как вы это делали?

    — У нас есть два процесса. Мы их называем «бэкенд» — это, собственно говоря, ReSharper — и «фронтенд», IDEA. Между ними осуществляется общение по нашему специальному протоколу, и по нему мы, по сути, гоняем view-model.

    — А он поверх чего, поверх сокетов?

    — Поверх сокетов. Мы про разные варианты думали, но этот нам подошёл больше всего. Сначала мы хотели гонять всю модель, которая есть у ReSharper. Есть, например, синтаксические деревья, которые строит IDEA для поддержки Java, но если бы мы полностью перегоняли синтаксические деревья для C#, это была бы очень дорогая операция, мы бы не вытянули перфоманс…

    — То есть, трафик данных?

    — Да, протокольный трафик очень велик. Поэтому мы гоняем очень легковесные модельки, только view-model, только то, что нам нужно отобразить для пользователя. Только информация для UI.

    — А синтаксическое дерево лежит на стороне ReSharper-а?

    — Да. То есть у ReSharper есть дерево, он его как-то обрабатывает, считает все анализы, и на сторону IDEA просто перекидывает несколько строк, например, с сообщениями из подсистемы инспекций.

    — Просто, насколько я понимаю, IDEA работает именно с неким деревом, которое в том или ином языке строишь и гоняешь. Здесь, видимо, пришлось сильно переделывать, да?

    — Да, мы это не используем, мы используем API’шки, например, «подчеркни красной линией здесь вот, потому что ReSharper сказал, что здесь ошибка». Мы не делаем анализа на стороне IDEA. Все анализы делает ReSharper. А от IDEA большей частью используем «показать UI».

    — То есть вы интегрировались с IDEA не там, где другие языки интегрируются. Многое ли для такой интеграции пришлось переписать в IDEA?

    — Нет, на удивление не так много.

    — А какие части ReSharper и IDEA переписывались для того, чтобы это всё работало?

    — Не так много пришлось править, больше просто подверстать некоторые API. У нас есть собственные коммиты в IDEA, но большая часть коммитов связана с тем, что мы берём какой-нибудь private и меняем его на public. Какой-нибудь метод никогда не вытаскивался вовне, а нам понадобилось его вызвать, потому что мы делаем то, что другие языки не делают. И, конечно, самая большая работа была проделана, чтобы ReSharper нормально запускался на Linux и Mac поверх Mono. Мы узнали очень много про кроссплатформенную разработку :) Недавно делали семинар на тему кроссплатформенности в Rider, уже доступна видеозапись.

    — У меня была история, что я ставил Mono на Mac через Homebrew, и на одном из ранних билдов у меня ReSharper просто отказался видеть такой Mono. Я понимаю, что, наверное, не самая сложная задача — пофиксить всё вот это. Но есть у тебя ощущение, что вы вот сейчас к публичному EAP с такого типа косяками справились?

    — Ну, мы разгребли основную массу самых мажорных косяков. Сейчас Rider — это IDE, которой реально можно пользоваться. Там не все фичи работают идеально, иногда где-то что-то отваливается, но большинство сценариев работает.

    — Понятно, что релиз — вещь продуктовая, но интересует чисто твоё субъективное инженерное ощущение: много ли ещё нужно сделать для того, чтобы уйти в продакшен? Какие вещи будете сейчас в первую очередь дорабатывать?

    — Нам осталось сделать не так много. В первую очередь, нужно поработать над стабильностью…

    — Падаете ещё?

    — Не то что бы падаем, но недавно, например, пришёл реквест: вот у меня ArchLinux, я поставил туда Rider, и у меня что-то там не работает. У нас, скажем так, нет большого опыта работы с ArchLinux, мы разбираемся… Это не основная масса наших пользователей, скорее экзотические сценарии.

    — Та же Java, например, сертифицируется не на всём Linux, есть очень строгое описание того, каким должен быть дистрибутив. По-моему, дело в том, что референс-платформой является Oracle Linux: условно говоря, Red Hat-подобный дистрибутив со всеми вытекающими последствиями. Про остальное Java гарантий не даёт, и интересно, что вы делаете в этом месте. Вы поставляете собственную JVM?

    — Да, мы таскаем с собой собственную Java и собственную Mono, поверх которой работаем. У нас нет задачи работать абсолютно везде или поддерживать «вот эти, вот эти, вот эти» версии Линукса, а остальные не поддерживать, мы просто, насколько это возможно, пытаемся сделать максимум пользователей счастливыми, чтоб они смогли пользоваться нашей IDE.

    — А в том, что касается .NET, вы что с собой таскаете?

    — Mono. Ну, на macOS и Linux — Mono определённой версии, а под Windows мы запускаемся на полном фреймворке — том, который стоит у пользователя.

    — C ним меньше проблем?

    — Да, потому что ReSharper — изначально продукт, который работает поверх полного фреймворка. А с Linux, конечно, возникло много проблем, мы много контрибьютим в сам Mono, много патчей накатываем на Mono, которое ходит с нами, чтобы нам поверх этого хорошо работать. Это большой объём работ.

    — Вы в upstream это контрибьютите?

    — Да, конечно. Мы пытаемся все changeset-ы, которые мы делаем, пропихнуть.

    — Много из Mono вытащили багов за этот год?

    — Я думаю, добрый десяток хардкорных багов нашли. Например, в Mono была плохо реализована работа с мьютексами. Там были именованные мьютексы, которых как бы нет на Linux и macOS, но есть в .NET. Поэтому пришлось как-то эмулировать с ними работу, она была эмулирована не до конца, и в исходниках NuGet’а — мы же должны полностью реализовывать работу своего NuGet. Мы две недели ловили этот Race Condition, который где-то там внутри возникал, потом выяснили, что он возникает не только с именованными мьютексами, но и с обычными, запатчили, потом заслали фикс в Mono, он уже попал в мастер-ветку.



    Настоящее и будущее .NET


    — Слушай, вот вся эта весёлая связка “Mono, Xamarin, Microsoft”, и вся история про разные рантаймы (Mono, классический, Core) — вот как вы со всем этим пёстрым зоопарком будете жить?

    — Короткий ответ — как-то будем. Мы пытаемся всё это поддерживать. Больше всего проблем, конечно, с CoreCLR, потому что это вещь, которая ещё, можно сказать, до конца не вышла. Вот буквально недавно Microsoft представили новую Visual Studio 2017 и вместе с ней новый тулинг для CoreCLR, в котором они опять всё поменяли.

    — То есть, подожди, была версия 1.0, про которую сказали, что стабильная, потом вышла 1.1…

    — Нет, есть две разные вещи. Есть рантайм, и есть тулинг к нему. Рантайм — это VM-ка, поверх которой мы бежим. А тулинг — это как мы это всё собираем.

    — То есть вышел новый тулинг.

    — Да. Вот был такой формат проектов, основанный на project.json-файлах, многие про него слышали или даже работали, Microsoft этот проект очень долго продвигал, говорил «будущее в json-ах», «переводите ваш проект в json-ы». А потом внезапно они говорят «ой, чё-то не пошло, мы возвращаемся обратно на csproj». Много месяцев тому назад объявили, что project.json — это уже legacy, поддерживаться не будет, но альтернативы не представили. И вот она буквально неделю назад появилась.

    — Если ты меня спросишь, какие у меня ощущения от истории с CoreCLR, то мне в голову приходит слово «хаос». Какие у вас ощущения с коллегами?

    — Отчасти, конечно, мы с тобой согласны, потому что очень много всего происходит, меняется в инфраструктуре, в отношении к .NET. Но я считаю, что это достаточно хорошо. Потому что .NET — такая платформа, которая очень много лет жила своей жизнью в рамках Windows-экосистемы, и внезапно Microsoft полностью поменяли стратегию, взяли курс на кроссплатформенность, Open Source и всё такое.

    И понятно, что такое за один день не делается, это гигантский объём работы. Сделать тот же CoreCLR, сделать дотнет кроссплатформенным, чтобы на мобилках всё работало и так далее. Понятно, что ребята хотят как можно раньше всё это сделать, и естественно, что делают какие-то ошибки, которые потом приходится признавать, откатывать, что-то менять… Это разумная цена, которую приходится платить за скорость развития современного дотнета.

    — Нет ли такого, что человек пишет на .NET, сегодня слышит одно, завтра другое, ему приходится всё переделывать несколько раз, он просто плюёт и говорит «нафиг я тут трачу кучу времени на переписывание, пойду-ка на другую платформу».

    — Здесь всё зависит от того, что конкретно ты разрабатываешь. Если ты разрабатываешь на том же дотнете, который когда-то был и сейчас есть (полном фреймворке для Windows), у тебя не должно быть таких проблем. У тебя все те проблемы, что и раньше, может быть, немножечко меньше.

    А если ты начинаешь разрабатывать на CoreCLR, то слово «preview» в названии должно тебя насторожить и подготовить к тому, что с тобой будет дальше.

    Есть люди, которые пытаются сидеть на bleeding edge, на самых последних технологиях, и влиять на их развитие, потому что Microsoft сейчас очень активно слушает комьюнити: если в новом дотнете что-то не нравится, сейчас самое время написать им фидбэк. А другие люди просто ждут, когда всё это станет стабильным.

    — Ты затронул очень интересную тему — дотнет и кроссплатформенность, дотнет и опенсорс. Давай про эти два больших блока поговорим. Вот про Linux, раз уж мы это затронули: .NET и Linux вместе уже какое-то время существуют. Стало ли за это время лучше?

    — Да! Прежде всего… У нас есть два рантайма, поверх которых мы можем бежать на Linux и Mac — это Mono и CoreCLR. Они разные, каждый интересный и заслуживает особого внимания.

    Mono — это проект, который разрабатывается с начала 2000-х, и чем дальше, тем стабильнее становится, его можно рассматривать как всё более и более серьёзный рантайм. Если люди, которые пытались что-то переводить на Mono пять-десять лет назад, страдали, то сейчас… Ну, мы тоже, конечно, немножко страдаем. Но ReSharper, в котором сотни проектов, миллионы легаси-строчек кода, которые писались с начала двухтысячных, пусть и немножко скрипя, завёлся и отлично работает поверх Mono. То есть развитие идёт, баги фиксятся, и в последнее время они фиксятся очень быстро.

    — По тому, что вы видите по своим клиентам: уходят ли они на CoreCLR?

    — Пока что сложно сказать. Можно сказать, что интерес к CoreCLR со стороны комьюнити очень большой, очень много людей следят за развитием, пытаются что-то делать, пробуют. Но всё это ещё превью, и делать какой-то энтерпрайз поверх CoreCLR ещё рано.

    — А что с Roslyn? Вышла новая Студия, что там у них с компилятором?

    — Roslyn развивается. Скоро выйдет C# 7, в новой Студии уже доступна превьюшка. С Roslyn всё хорошо.

    — C# 7 идёт с Roslyn — прямо из коробки? Roslyn прогрессирует за это время?

    — Да. В нём фиксят баги, развивают, и… Самая главная возможность, которую мы получили, перейдя со старого легаси-компилятора на Roslyn — это то, что мы теперь можем проще развивать язык. Можем больше концентрироваться на том, какие фичи нужны с точки зрения языка и как их правильнее реализовать, чем на имплементации. На старом компиляторе было очень тяжело дописывать новые фичи, с Roslyn это стало в разы проще.

    — Вы пытались затащить к себе куда-нибудь Roslyn и что-нибудь с этим сделать?

    — Ну как. Мы используем его как компилятор. Он работает под MS-билдом, и с помощью него компилируются новые проекты. Но в отношении анализаторов или инспекций то, что он предоставляет, нам просто не нужно, потому что в ReSharper реализовано намного больше. Я бы сказал, в разы больше, очень крутые инспекции, более интеллектуальные. И Roslyn легко может сожрать два гигабайта памяти. В этом плане кодовая база ReSharper всё-таки поэкономнее относится к памяти, активно использует кэши и так далее. То есть у нас от перехода на Roslyn не было бы никакого профита, одни проблемы.

    — Поговорим о перфомансе. CoreCLR, Roslyn по сравнению c Mono с классическим legacy-компилятором. То есть два рантайма, у них будет разный перфоманс. Как тебе это видится?

    — Однозначно сказать очень сложно… С недавних пор есть новый JIT-компилятор RyuJIT. Сейчас доступна только 64-битная версия, причём как в полном фреймворке, так и на CoreCLR. И в CoreCLR 1.2.0 нам обещают ещё и x86-версию.

    RyuJIT — очень интересный проект. С одной стороны, хорошо, что ребята начали его делать, потому что старые JITы тяжело было развивать, они тащили с собой много проблем, много хаков для старых версий .NET вроде 2.0. Но что получилось плохо — это что RyuJIT, например, уступает старым легаси-JIT’ам в некоторых моментах по перфомансу. То есть там ребята делали упор на то, чтобы скорость JIT’инга была как можно больше. И из-за этого некоторые хорошие оптимизации не применяются.

    Но хорошая сторона в том, что RyuJIT сейчас очень активно развивается. Он очень активно разрабатывается на гитхабе, ребята улучшили архитектуру так, что, например, в RyuJIT встроена хорошая интеграция по работе с AVX и SSE-инструкциями. И оптимизации развиваются. Можно прийти на GitHub, сказать «ребята, вот есть такая хорошая оптимизация, но вы её почему-то не делаете, а вроде можно легко дописать». И вполне возможно, что они возьмут эту оптимизацию и её завтра или через месяц сделают.

    — А ты сам контрибьютишь куда-то?

    — Я делал пару не особо крутых коммитов в CoreCLR и CoreFX. Больше участвую в обсуждениях, завожу тикеты «ребята, давайте сделайте вот это». Потому что рантайм — это всё-таки такой большой проект, есть люди из сообщества, которые активно работают над ним, но нужно понимать, что здесь достаточно высокий порог вхождения, и прежде чем какую-то полезную оптимизацию для компилятора напишешь, нужно очень много времени изучать кодовую базу.

    — Лёша Шипилёв, который был здесь года полтора назад, говорил, что есть очень серьезный порог вхождения — это несколько лет для любых компиляторщиков и вообще системщиков, а время, через которое человек начинает приносить пользу — это вообще чуть ли не десять лет. Это оень серьёзный барьер для входа.

    — Ну, я бы не сказал, что в новом .NET это десять лет, потому что как-то люди входят…

    — Очень во многом это всё было переделано и переписано как раз для того, чтобы порог входа был ниже, потому что иначе невозможно же.

    — Да, абсолютно верно.

    — Вы взаимодействуете по этим вопросам с Microsoft. Вот эта их история про опенсорс, через который вы всё это делаете — GitHub, пуллреквесты — это реально работает? В разрезе .NET-вещей — это больше формальность или работающая схема?

    — Это абсолютно работающая схема. Microsoft сейчас — топовый контрибьютор на GitHub. Очень много обсуждений идёт со стороны сообщества. То есть люди, особенно хорошо понимающие в дотнете, которые понимают, что в нём было не так, хотят как-то на это повлиять. Сейчас любой может создать issue на GitHub, это будет рассмотрено точно так же, как issue от сотрудника Microsoft, будет вестись…

    — Или не будет.

    — Или не будет! Но так же, как и для любого другого сотрудника Microsoft. И реально эти issue закрывают. Также ты можешь сделать пуллреквест, если он хороший, не нарушает никакие гайды, не несёт в себе никаких проблем и ты его покрыл тестами, его вполне могут принять.

    Есть ещё такая интересная история. Новый ASP.NET-сервер Kestrel сейчас в топ-10 линуксовских веб-серверов по скорости. Его разогнали по перфомансу очень сильно. Есть популярный бенчмарк, который гоняется для всех серверов…

    — Для всех для .NET-серверов или серверов вообще — типа nginx, Apache?

    — По всем — Java, C++, всё на свете. И Kestrel там вошёл в топ. И во многом он вошёл благодаря такому человеку, как Бен Адамс: он не из Microsoft, он пришёл со стороны комьюнити и начал контрибьютить в Kestrel.

    — Это майкрософтовский проект?

    — Да. То есть Сore Team майкрософтовская, а это просто человек со стороны пришёл, начал очень активно контрибьютить перфоманс-улучшения в сервер, и разогнал его.

    Microsoft и Open Source


    Есть ли вообще у Microsoft, по твоему ощущению, понимание того, что такое опенсорс, как это работает?

    — Да. Мне очень нравится Microsoft в последние два-три года, когда Сатья пришёл, всё стало совершенно по-другому. У Microsoft есть понимание, возможно, оно не совсем было в самом начале, но сейчас есть.

    — То есть они адаптировались?

    — Да, они адаптировались очень круто, это не только про Open Source, но и про кроссплатформенность. Вот ты слышал, наверное, Microsoft недавно присоединилась к Linux Foundation.

    — Да, это был мой следующий вопрос: зачем они это делают, на твой взгляд?

    — На мой взгляд, они поняли, что раньше что-то делали не так, поняли, что Linux их тоже интересует как операционная система. Например, они продвигают такой продукт, как Azure…

    — «Например»! Это сейчас вообще топовый продукт Microsoft. Если ты послушаешь их евангелистов, посмотришь их конференции и блоги, увидишь, что Azure, наверное, вообще номер один.

    — Ну, я не знаю, как по номерам, но ты совершенно прав, один из топовых сервисов, они делают на нём очень большие деньги. И вот, как они недавно заявляли, у них треть серверов крутится под Linux.

    — Тогда для них это прямой business value.

    — Да, причём у них теперь партнёрство с Red Hat. Red Hat теперь тоже продвигает, что .NET — это правильный путь писать под Red Hat…

    — То есть можем ли мы говорить, что схема такая: Microsoft двигает Azure, поскольку видит в нём деньги. Очень многие клиенты хотят Linux (потому что это дешевле, чем Windows, и по многим другим причинам). Соответственно, Microsoft пытается сделать всё, чтобы этих кастомеров не потерять и чтобы они приходили с этим линуксом в Azure.

    — Ну, я думаю, это как минимум одна из причин.

    — А какие ещё, на твой взгляд? Вряд ли чистым альтруизмом можно объяснить всё это движение в сторону Linux и Open Source.

    — Есть ещё рынок мобильных приложений. Это приложения для телефонов и планшетов. Microsoft, мягко говоря, чуть-чуть опоздал с этим рынком. Им уже завладели Apple и Google. С этим нужно было что-то делать.

    — Такой гигант — и так плохо вышел на рынок. Не секрет, что Windows Phone имеет небольшую экосистему и низкий процент популярности.

    — А почему так получилось? В Windows Store мало приложений. Раз мало приложений, мало людей покупает соответствующие девайсы. Раз мало людей покупает девайсы — мало девелоперов делает приложения.

    — Ну да, это замкнутый круг.

    — Но есть интересный вариант, как в перспективе из него можно выйти. В частности, Microsoft сейчас приобрела компанию Xamarin и активно продвигает Mobile Development на C#.

    — Мы с командой в декабре проведём уже шестой DotNext (в Хельсинки) и седьмой (в Москве), на которых ты выступишь. На DotNext периодически всплывает тема, например, Xamarin.Forms. Мы каждый раз смотрим на её популярность, и каждый раз она в самом низу. По той аудитории, которая приходит к нам, такое ощущение, что это никому не интересно.

    — Ну, я бы сказал, что это специфическая аудитория. Всё-таки на DotNext больше приходят энтерпрайз-девелоперы, а людей, которые занимаются мобильными приложениями, у нас не так много, и отчасти это из-за того, что на дотнете их раньше было толком не подевелопить. А сегодняшняя тема с Xamarin идёт последние пару-тройку лет, возможно, даже меньше.

    Сейчас C# — это действительно такой язык, с помощью которого можно написать для Xamarin приложение, которое будет работать сразу и под Windows, и под Android, и под iOS. Там есть проблемы, но в целом ребята хорошо сделали продукт. Что делает саму эту платформу разработки привлекательным вариантом для разработчиков.

    Речь не идёт о топовых приложениях, если ты хочешь попасть в топ Google Play или App Store, тебе придётся писать native. Но если нужно простое приложение, приложение-визитка с информацией про твою компанию или с одной кнопкой «купить билеты», тебе не нужен супермощный функционал, тебе не нужна суперскорость, тебе нужно быстро наклепать приложение, которое даёт тебе простой контент, простой функционал, и желательно под все платформы, то C# — это отличный выбор.

    — А почему именно в топ не попасть?

    — Всё-таки есть определённые проблемы с перфомансом. Если не знаешь заранее, на какой платформе будешь запускаться, сложнее дёргать за какие-то ручки и низкоуровневые API, разные платформы предоставляют разный набор API. И не всегда получается для сложного интерфейса сделать так, чтобы приложение выглядело как родное. Всё равно в native больше API, возможностей использовать фичи нативного UI, и так далее.

    По срезу аудитории того же Rider, очень много людей проявляет интерес к Xamarin, к разработке под мобилки, многие этим занимаются.

    — То есть, на твой взгляд, будущее у этого всего может быть?

    — Да, «может быть» — самая правильная формулировка. Происходят инвестиции в этот стек технологий, его популярность растёт.

    — Быстрее, чем популярность .NET в целом?

    — Это очень сложно сравнивать.

    — Вы со стороны своих инструментов Xamarin поддерживаете?

    — Возможно, ещё не так хорошо, как хотелось бы, но, например, к Rider 1.0 хотим сделать хорошую поддержку, чтобы можно было комфортно девелопить под мобилки.



    BenchmarkDotNet


    — Мы сейчас уже заговорили про перфоманс, и мы с тобой так и познакомились ещё до твоей работы в JetBrains: ты писал инструмент для перфомансных замеров, микробенчмарков и тому подобного, который сейчас называется BenchmarkDotNet. Что у тебя сейчас с ним происходит?

    — Эта библиотека развивается, недавно нас взяли в .NET Foundation, это очень большой шаг для библиотеки, там пока не так много проектов.

    — А кто там, кроме BencmarkDotNet?

    — Ну, там изначально Roslyn, ColeCLR (с RyuJIT в составе), Entity Framework, и вот недавно Microsoft начал брать проекты со стороны, например, Cake, это альтернативная система сборки для .NET. Есть несколько десятков проектов.

    — Это хороший промоушен для вас, или вы пока не видите увеличенного количества скачиваний?

    — Резкого роста пока не произошло, но это в любом случае очень хороший шаг для библиотеки: и в плане пиара, и в плане доверия людей. Одно дело — когда это пишет какой-то непонятный Андрей откуда-то, другое дело — когда это проект .NET Foundation.

    — А нужны ли вообще людям микробенчмарки? Условно говоря, я понимаю, зачем Шипилёв пишет микробенчмарки в Java: он разработчик платформы, и им с коллегами надо понимать, с какой скоростью в платформе работают те или иные вещи, причём делать это на микроуровне. А вот конечному разработчику приложения это нужно?

    — Зависит от того, что за приложение. Мы с тобой уже обсуждали Kestrel, который выстрелил, вот там тот же Бен Адамс BenchmarkDotNet вовсю использует для тюнинга производительности. Для тюнинга того же рантайма — я видел, некоторые ребята использовали, чтобы обкатать некоторые фичи…

    — Ты сейчас говоришь про рантайм и сервер, которые внутри Microsoft зародились. Я понимаю, что BenchmarkDotNet — это инструмент, который нужен людям из Microsoft. А остальным?

    — Есть ещё люди, которые просто разрабатывают определённые библиотеки, и делают упор на high performance. Хотят, чтобы их библиотеки были самыми быстрыми. Потому что есть ещё 20 библиотек, которые делают то же самое, и им надо чем-то выделиться. Некоторые реально используют BenchmarkDotNet для какой-то перфоманс-работы, некоторые используют, по-моему, просто для пиара, померили и говорят «вот у нас хорошо».

    — Ну это беда, потому что намерить с помощью инструмента можно что угодно — это опасно, это можно сделать это в определённых маркетинговых целях, но в реальности такие замеры ничего не скажут.

    — Да, абсолютно согласен с тобой, но… Есть ещё одна проблема. В Java-мире уже достаточно давно есть JMH, и большая часть народа знает, что тебе нужен бенчмарк — бери JMH…

    — Знаешь, я видел случаи, когда люди берут JMH, строят по нему графики и говорят «A быстрее, чем B». Но в реальности это ересь.

    — Да, есть много таких случаев, но, как минимум, у тебя не будет большого количества детских ошибок. Если ты где-то ошибёшься, то уже на дальнейших этапах. За тебя сделают прогрев, за тебя сделают N итераций, посчитают какие-то статистики.

    То, что ты используешь какой-то инструмент для бенчмаркинга, не делает твой бенчмарк автоматически правильным. Тебе всё равно нужно многое понимать о том, как работает компьютер, как устроен рантайм. Но ты избежишь простых типичных ошибок, особенно если не разбираешься в бенчмаркинге. Получишь какие-то инструменты для того, чтобы всё это автоматизировать, то есть тебе не надо будет для каждого бенчмарка руками писать прогрев, писать всю эту инфраструктуру, которая это запускает, у тебя уже есть готовая тулза.

    — Ты при разработке этого смотришь на JMH?

    — Да.

    — BenchmarkDotNet получился другим или похожим? И если другим, то в чём ключевое отличие?

    — Он получился другим. Во-первых, он изначально другой, потому что в Java и .NET разные проблемы, с которыми надо бороться. В Java их намного больше. Там в разы сложнее бенчмаркать. Потому что Java умеет очень хитро делать деоптимизации, может перекомпилировать методы, и очень сложно сделать прогрев.

    — С другой стороны, в Java единый JVM, который отличается от платформы к платформе, но в целом и компилятор более-менее один, и рантайм один, и так далее. В .NET же есть старый CLR, новый CLR, Mono — это разные рантаймы, и наверняка там приходится разные проблемы обходить. Я не специалист по JMH, но у меня ощущение, что он очень сильно заточен под HotSpot, и что использовать его с другими виртуальными машинами будет трудно, если вообще возможно. Как ты решаешь такую задачу, ведь в .NET есть совершенно разные рантаймы?

    — В это вкладывается много сил. Одним из главных достоинств моей бенчмаркалки я считаю то, что она позволяет сделать бенчмарк сразу для разных платформ. Навешал три атрибутика, и сразу запустил свой код для Mono, для полного фреймворка и для CoreCLR. Причём можешь больше атрибутиков написать и запускать ещё с разными параметрами, какие-то флажки повыключать-повключать. И всё это посравнивать.

    Это очень удобно в том отношении, что если ты хочешь перенести какой-то код с полного фреймворка на Mono и интересуешься, как это скажется на производительности, ты можешь отдельные части аккуратно посравнивать. Это первый момент. Второй — как ты совершенно правильно отметил, люди не понимают в производительности, не понимают, как делать замеры, даже если у них есть хороший инструмент, они всё равно могут легко сделать направильные выводы. И JMH — это больше инструмент для людей, которые понимают, что они делают. Но по факту большая часть людей не понимает. Не потому что они там глупые, а просто потому что они этой темой не занимаются, а бенчмаркинг требует очень много сил и времени.

    — В чём преимущество BenchmarkDotNet перед, скажем, профилировщиками от JetBrains?

    — Профайлинг и бенчмаркинг — похожие деятельности, многие их путают, но это совершенно разные вещи. Профайлинг — это ты просто снимаешь профиль своего приложения, как оно бежит, один снэпшот. А бенчмарки помогают изучать разные перфомансные эффекты, разбираться, как у тебя система работает в тех или иных условиях, получать довольно высокий уровень точности.

    Это не та деятельность, которая нужна всем. Если я вижу, что Rider начал очень медленно работать, я снимаю профиль, вижу, что какая-то новая функция работает десять секунд вместо одной, смотрю, что там не так, исправляю. А когда речь заходит о наносекундах и микросекундах, сравнении рантаймов и конфигураций, уже просто так не получишь с помощью профайлинга нужный уровень точности, и будет очень сложно сравнить разные конфигурации.

    — Мне очень нравится в том же JMH, что там, по сути, есть интеграция профилировщиками с разного уровня. Там можно запустить с таким, с сяким, посмотреть стеки по процентам, байткод, процессорные инструкции, это позволяет на всех уровнях увидеть проблему. Есть ли у тебя какие-то такие интеграции?

    — Да. Мы сейчас активно пишем плагины к BenchmarkDotNet. В частности, у нас есть диагностики, позволяющие, например, следить за размером выделенной памяти.

    — То есть footprint?

    — Ну да, сколько памяти на метод ушло. Сейчас мы немного переписали логику, она теперь с очень хорошим уровнем точности показывает memory traffic. Другая диагностика показывает, какие у тебя методы за-JIT-ились, а какие нет. Это направление мы тоже развиваем.

    — Кто работает над проектом? Наверное, главный контрибьютор — это ты, я знаю ещё Адама Ситника. Кто ещё?

    — Ещё Мэтт Уоррен, хороший девелопер из Великобритании. Он многое в отношении диагностик сделал, много полезных обсуждений с ним было.

    — Какие-то известные люди к вам приходили?

    — Ну вот начинали это делать ещё с Джоном Скитом. Он изначально ничего не контрибьютил, но с Джоном можно очень хорошо пообщаться, он может подсказать очень хорошие вещи.

    — Джон вроде бы к нам в Питер на DotNext собирается?

    — Да, совершенно верно. В конце мая будет петербургский DotNext, он там один из спикеров.

    — А что вы Сашу Гольдштейна не подключите, например?

    — Саша нам тоже контрибьютил что-то.

    — Меня удивляет его удивительное спокойствие. И у Саши есть ещё такое свойство — он знает весь стек насквозь до деталей работы в железе. Очень важная часть, когда ты работаешь над бенчмарком — понимать железо. Вот что ты сам в этом отношении чувствуешь о своём понимании?

    — Я чувствую, что за последние несколько лет, за которые я написал очень много бенчмарков, я стал понимать железо намного лучше. Железо — это, наверное, такая вещь, которую никто никогда не понимает до конца, но можно бесконечно качаться.

    Конечно, никакой Intel не рассказывает же, как у них всё внутри работает, потому что патенты, ноу-хау, конкуренты, AMD, ARM, Samsung— да кто угодно.

    — Да. Я иногда вылавливаю хитрые перфомансные эффекты, которые не могу объяснить публичными спецификациями Intel, то есть они иногда внутри делают что-то очень хитрое…

    — Ты не пытался им самим вопросы задавать?

    — Кому, Intel?

    — Ну да, «вот у нас бенчмарк тут странный, вы не могли бы подсказать». Вот ты же работаешь с Microsoft, и для тебя это естественно — работать с большим вендором. Что мешает тебе так же работать с Intel?

    — Во-первых, как мы с тобой уже обсудили, Microsoft сейчас стал более открытой опенсорсной компание. Intel в этом плане, скорее всего, намного более консервативный — это раз…

    — Есть же люди, которые, скорее всего, со стороны Intel контрибьютят в эти замечательные майкрософтовские проекты. В Java они точно есть, там ребята из Intel приходят и говорят: «У нас новый intrinsic, вот вам патч, который...»

    — В .NET, боюсь, это намного менее выраженно.

    — Мне кажется, между Intel и Microsoft должны быть хорошие связи.

    — Неплохие. Но такого прямо открытого налаженного процесса я не наблюдаю. И я боюсь, то, что меня интересует, составляет коммерческую тайну, и мне просто об этом никто не расскажет.

    Компиляция в native и подведение итогов


    — Ну ты попробуй, это хорошая история. А есть ещё история в современном .NET, связанная с перфомансом: компиляция в натив. Вот ты что-то меряешь в случае нативной компиляции?

    — Пока что нет. Там трудности в непроработанности технологии.

    — То есть она просто сырая?

    Ну смотри, есть разные виды нативной компиляции. NGen, который испокон веков в дотнете есть — это не очень интеллектуальная вещь, простая тупая ahead of time-компиляция.

    — Что она даёт? Она же наверняка даёт не очень хороший перфоманс. Это многопроходный хотя бы компилятор? Я почему задаю этот вопрос: в современной GCC есть сценарии, на которых они делают по 70 проходов. То есть они по internal representation вот так вот много раз бегают.

    — NGen в этом плане, конечно, тупее, но там есть, например, такая вещь, как profile-guided optimization: когда ты используешь профиль рабочего приложения, чтобы как-то более правильно заранее расположить.

    — То есть, запускаешь своё приложение с некоторым агентом, этот агент запускает некую статистику, потом ты её на входе скармливаешь NGen’у, и он что-то делает?

    — Грубо говоря, да, и по идее, это должно хорошо работать, но на практике очень мало людей этим пользуется. Выгода в основном в том, что экономишь на времени JIT-компиляции. То есть людям, которым критично время холодного старта, чтобы большая программа завелась и сразу начала что-то быстро делать, разумно это использовать. Остальным… Ну, какого-то особого профита я не наблюдаю, и никто не заморачивается.

    — Но если хорошо скомпилируешь, то нет накладных расходов на компиляторные потоки. JIT-компилятор ведь работает в той же машине. Это footprint, всё это отъедает память, хочется понять, какие перспективы у этого всего.

    — Перспективы немножко в других технологиях.

    — Хорошо, мы поговорили про NGen, а что сейчас происходит, новая компиляция в натив?

    — Есть .NET Native. К сожалению, он пока работает только для универсальных Windows-приложений. Работает, судя по отзывам, хорошо.

    Для обычного .NET, консольных приложений, пока нельзя использовать .NET Native, к сожалению. Работа над этим ведётся, есть ещё один проектик, который позволяет обычные .NET-бинарники в native компилировать. Там тоже есть разные подходы, например, есть вариант делать компиляцию через LLVM. Ещё есть вариант с использованием C++ компилятора на бэкенде, то есть мы перегоняем весь наш .NET в C++, и дальше уже компилируем.

    — В какой C++?

    — Предположительно в майкрософтовский.

    — В managed?

    — Нет, в обычный. Сложно ещё про эту технологию рассуждать, потому что она не готова, и непонятно, в каком виде она будет в итоге, когда и если она будет готова. Потому что Microsoft в начале начали очень радужно рассказывать, что вот, уже почти всё готово, но потом оказалось, что оно не очень готово, и как-то сейчас они эту тему замяли, тихонько что-то девелопят на гитхабе, но не особо про это рассказывают.

    — У меня из нашего разговора сложилось впечатление, что в попытке покрыть всё Microsoft покрывает не ровными областями, а сначала так, потом этак, и одно и то же становится возможно сделать многими способами. И возникает вопрос: я хочу что-то написать — как мне это сделать? Какой рантайм выбрать? Я ставлю Rider, думаю «вот у меня новая крутая IDE, я C#-программист, у меня новый проект». Как мне выбрать правильную технологию для него?

    — Прежде всего нужно всё-таки ориентироваться немножко в том, что происходит в новом .NET-мире.

    — И это трудно, потому что этого как-то резко стало много. Мне тяжело ориентироваться, и думаю, что человеку, который большинство времени пишет продакшен-код для энтерпрайз-проекта, не сильно легче. И я вижу тут проблему. Прокомментируй, пожалуйста: вот тебе с этим зоопарком как живётся в Rider?

    — Тяжело. Постоянно приходится держать руку на пульсе, разбираться с новыми технологиями, желательно начинать в день их выхода, потому что сразу приходят недовольные пользователи, бывает, ещё на этапе preview. Поэтому активно приходится изучать каждую новую версию тулинга, каждую версию этих рантаймов, следить за этим всем. Это вполне реально делать. Но этим, конечно, нужно заниматься.

    Если мы говорим о старых проектах, их чаще всего разрабатываешь на чём-то, что хорошо понимаешь. А что касается новых, знающие люди должны делать соответствующей рисерч, на какой платформе более рентабельно делать новые проекты какого размера.

    — В своё время у Джоэла Спольски была программная статья про Microsoft. Он писал, что Microsoft постоянно делает новые технологии и сама на этом зарабатывает, а всем другим не даёт. И что люди, работающие с Microsoft, вынуждены постоянно заниматься переписыванием под новые MS-стандарты, платформы и среды. Это он писал лет 15 назад, и как-то не сильно всё изменилось. Люди не business value делают, а переписывают код с одного рантайма на другой.

    — Это правда. Единственный совет, который я могу дать — не использовать для серьёзного продакшена тех технологий, которые вышли вчера. Если продукт вышел 2-4 года назад и развивается — про него можно подумать.

    — Есть ещё история про экосистему: если продукт существует 2-3 года, то появляется некоторое количество документации, ответов на Stack Overflow, статей на Хабре или Medium, в блогах. В общем, не перегибает ли тут Microsoft палку? Вам тут как?

    — Тяжело. У нас много разработчиков ходят по офису и жутко матерятся, что вот, опять Microsoft старую технологию закрыл, новую открыл.

    — За вами же легаси тянется. Вот вы делаете ReSharper, и он что-то поддерживал. И пусть Microsoft это уже не очень поддерживает, вы вынуждены это тянуть. Если в своём коде я могу при выходе несовместимого 1.1 всё переписать и 1.0 выкинуть, то у вас же будут кастомеры, которые сидят на 1.0. И как вы на это закладываетесь?

    — Конечно, тяжело разрабатывать, приходится вбивать много костылей, но мне кажется, что ты всё-таки немножко драматизируешь. Если взять историю с CoreCLR, то там ещё стабильная версия тулинга не вышла. Было preview 2, недавно вышло preview 3. Мы preview 2 ещё поддерживаем, будем поддерживать, грубо говоря, N месяцев, пока все не обновятся. Потом эту поддержку можно будет выкинуть, поддержать preview 3, и в конце концов 1.0. И вот уже stable-версию будем поддерживать долго.

    Но это одна-единственная подсистема Rider, ну, с небольшими костылями. Не нужно перелопачивать весь код. Анализаторы C# работают вне зависимости от того, какой у тебя рантайм, какие-нибудь инспекции тоже, им это не важно. Проблема с тем, чтобы сбилдить, запустить, и просто у нас есть там отдельные подсистемы, которые отвечают за сборку под ту или иную версию того или иного рантайма.





    Пообщаться с Андреем можно будет уже в ближайшую пятницу в Москве на конференции DotNext, где он сделает доклад о скорости арифметических операций в платформе .NET.
    JUG.ru Group 963,52
    Конференции для взрослых. Java, .NET, JS и др. 18+
    Поделиться публикацией
    Комментарии 60
    • –6
      Что то какая то желтая статья.

      Roslyn есть гигабайты памяти

      Что то не замечал такого в VS 2017 RC
      но Студия с каждой новой версией потребляет всё больше памяти

      Тоже самое с VS 2017 RC, не замечал.
      • +8

        А мы целенаправленно следим за этим и постоянно проверяем самые разные проекты. Если солюшн маленький, то жить ещё можно. А вот когда у вас сотни проектов и миллионы строк кода, а вы что-нибудь активно рефакторите, то ситуация с памятью становится грустной (в том числе в VS 2017 RC).

        • +7
          Миллионы строк? Да у меня есть проекты на несколько сотен тысяч строк и уже тормоза ощутимые, по сравнению с новыми, почти голыми проектами… Да еще не оставляет впечатление, что на предыдущем ReSharper'е меньше тормозило, хотя студия та же самая.
          • 0
            А я эксперимент проводил. Даже на пустых проектах R# не успевает за моим печатаньем.
        • +5
          А решения у вас каких размеров? У меня студия меньше 1гб памяти не потребяла на 20+ проектах в решении.
        • –11
          ReSharper не тормозит, он работает как раньше и даже быстрее...
          Visual Studio потребляет всё больше и больше памяти. Предпосылок, что будет потреблять меньше, нет
          Ни интервьювер, ни интервьюи не понимают, о чём говорят, видимо.
          • +9
            интевьюер — возможно. Интервьюируемый — понимает все вплоть до мельчайших деталей, уверяю вас :)
            • –4
              Я тоже так думаю, на самом деле. Но всё-таки обидно читать такую откровенную ложь и саморекламу от JetBrains.
              • +5

                Никакой лжи тут нет. Я каждый день смотрю на снэпшоты R# и Rider и прекрасно понимаю, почему имеются определённые проблемы со скоростью в VS. Тот же самый код отрабатывает мгновенно в Райдере, что наводит на определённые размышления. Вы можете самостоятельно снять профиль работы студии и Райдера и разобраться что там и как. Никого обмануть я не пытался, а просто озвучивал собственное честное мнение. Могу подписаться под каждым словом.

                • +1
                  JetBrains активно читают и пишут на хабр и реддит. Мне кажется, вам должно быть известно популярное мнение о R#. Учитывая это, ваше «мнение» о том, что «ReSharper не тормозит, он работает как раньше и даже быстрее» выглядит именно как вранье, пиар и затыкание дыр. На хабре вы можете посмотреть топики про решарпер, в том числе те, в которых я пишу вам хейт-комменты, и увидеть, что у всех, оказывается, всё тормозит. Несколько ссылок на аналогичные отзывы с реддита: раз два три четыре пять шесть. В итоге, у меня самое главное мнение – своё, куча совпадающих чужих мнений, и одно мнение обратное, пристрастное.

                  Насчет 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 нейтральный или отрицательный, с памятью в студии лучше, чем когда-либо.
                  • +5

                    Вам не кажется, что как минимум некорректно сравнивать производительность голой студии и студии_с_решарпером/райдера? Очевидно, решарпер будет влиять на производительность из-за 100500 фич, анализов и т.п. Если та же скорость загрузки солюшна в голой студии и райдере одинаковая, то это плохие новости для студии, поскольку райдер за это же время делает гораздо больше и дает гораздо больше фич.


                    По сути. Я на работе пользуюсь райдером как основной IDE уже около трех месяцев. В солюшне около 200 проектов. До этого была студия 2013 + решарпер с включенными тяжелыми фичами (solution-wide analysis, r# build, вот это все). В 2015 на моем проекте было еще хуже по памяти, пришлось вернуться на 2013.
                    Наблюдения:


                    1. От запука студии до возможности начать работу запросто проходило 5 минут, до этого дикие тупняки или просто зависание UI. В райдере можно работать через минуту, если не меньше.
                    2. Студия во время работы периодически тупила и зависала на несколько секунд даже просто при вводе текста. Если запускаешь сборку, вообще лучше ничего не трогать и не кликать в интерфейсе — виснет. Райдер в процессе работы не зависает, сборка почти не влияет на производительность (справедливости ради, последний eap пару раз в день полностью вешается секунд на 5-10, в предыдудщих такого не было).
                    3. В студии сделать пулл или переключить ветки — это боль и скорее всего необходимость выгружать солюшн и загружать заново (см п.1), иначе виснет от минуты до бесконечности. Райдер мгновенно подтягивает изменения.
                    4. Студия в фоне иногда запросто выжирала 80-90% цпу. Ты сидишь в браузере, а там где-то что-то происходит и тормозит вообще все. Две запущенных студии на пару выжирали 100% цпу.
                    5. Студия падала 1-5 раз в день, видимо из-за OutOfMemory.

                    Как видите, мой опыт полностью противоположен вашему, мне райдер существенно повысил эффективность работы и сохранность нервов.
                    В JetBrains не работаю, за положительные отзывы от них денег не получаю.

                    • –1
                      Вам не кажется, что как минимум некорректно сравнивать производительность голой студии и студии_с_решарпером/райдера? Очевидно, решарпер будет влиять на производительность из-за 100500 фич, анализов и т.п. Если та же скорость загрузки солюшна в голой студии и райдере одинаковая, то это плохие новости для студии, поскольку райдер за это же время делает гораздо больше и дает гораздо больше фич.
                      Год-два назад я бы принял это как аргумент. Но сейчас R# практически не предоставляет новых фич, которые могут замедлить загрузку проектов.

                      Как видите, мой опыт полностью противоположен вашему
                      Не вижу. Во всех ваших претензиях следует заменить «студия» на «студия с R# и Solution-wide analysis». Мне кажется, ваш комментарий лишь подтверждает мою точку зрения – решарперовский Solution-wide analysis тормозит так, что его просто невозможно использовать. Ну и немного ССЗБ.

                      Кстати, вот про перезагрузку проектов (переключение) я забыл написать! Да, в старых студиях перезагрузка проекта была не очень быстрой. Вместе R# это, опять же, просто невозможно было использовать – вы абсолютно правы. Причём конкретно подавляющую вину R# я экспериментально подтверждал много-много раз. Но в VS 2017 этой проблемы практически нет, проекты перезагружаются очень быстро.

                      Добавлено: сборка через R# Build у меня практически не нагружает саму студию. И после завершения тормозов R# нет, в отличии от нативной системы сборки. Может что-то изменилось в последних версиях?
                      • +3
                        Во всех ваших претензиях следует заменить «студия» на «студия с R# и Solution-wide analysis».

                        Да, но накой мне сравнивать голую студию с райдером, если это абсолютно разный уровень по фичам? Это как nokia 3310 с айфоном сравнивать, если утрировать. Я сравниваю два варианта, предоставляющих мне одинаковые возможности по функционалу.


                        решарперовский Solution-wide analysis тормозит так, что его просто невозможно использовать. Ну и немного ССЗБ.

                        Удивительно. В студии тормозит, в райдере не тормозит. Может, дело в студии?


                        Но в VS 2017 этой проблемы практически нет, проекты перезагружаются очень быстро.

                        Вы про кнопку "перезагрузить солюшн" вместо "перезагрузить проект"? Или они таки перезагрузку отдельного проекта оптимизировали?

                        • –1
                          Да, но накой мне сравнивать голую студию с райдером, если это абсолютно разный уровень по фичам? Это как nokia 3310 с айфоном сравнивать, если утрировать. Я сравниваю два варианта, предоставляющих мне одинаковые возможности по функционалу.
                          А вы попробуйте VS 2017.

                          Удивительно. В студии тормозит, в райдере не тормозит. Может, дело в студии?
                          А что есть в Rider аналог SWA? Тот процессинг файлов сразу после открытия проекта? Не увидел как-то я от него больших полезных эффектов; всякие окошки TODO продолжали загружаться при попытке их открыть. Да и подсветка кода в это время не работала.

                          Вы про кнопку «перезагрузить солюшн» вместо «перезагрузить проект»? Или они таки перезагрузку отдельного проекта оптимизировали?
                          Не очень понял, что вы имеете ввиду, но да, загрузка проектов была оптимизирована.
                          • +2
                            А вы попробуйте 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. Если действительно оптимизировали, то да, круто, но надо пробовать.

                            • –1
                              Для чего? Вы имеете ввиду голую 2017, или с тем же самым, чем я пользуюсь в 2013?
                              Голую 2017. Как я говорил выше, у R# не так много много фич, которых нет в 2017, и они не тормозят (или не должны тормозить) загрузку проектов.

                              View->Tool Windows->Errors in solution открывает такое же окошко SWA, что и в студии. Это ровно та же самая фича.
                              В таком случае, у меня SWA работает одинаково. В студии тормоза ощущаются сильнее из-за того, что выполняется в том же процессе, и, вероятно, из-за каких-то багов или несогласований с моделью студии (я имею ввиду проблемы вроде постоянного анализа после VS билда). Мне кажется, здесь вина именно R# – анализаторы Roslyn с такой проблемой тоже раз в месяц сталкиваются, но VS их принудительно выключает и предлагает включить.
                              • +2
                                Голую 2017. Как я говорил выше, у R# не так много много фич, которых нет в 2017

                                Серьезно? Куча рефакторингов, билд, юнит-тесты (в студии это есть, но неудобно), continuous testing, крутые навигации и поиск, посветка всяких интересных ошибок, code cleanup, генерация кода, поддержка JS, CSS, HTML с теми же самыми анализами, рефакторингами и т.п. Если говорить о райдере, то еще поддержка VCS, интеграция с issue trackers.
                                Я понимаю, что многие этим всем не пользуются, но я вот люблю выжимать из инструментов все, на что они способны. Когда я вижу новую фичу, которую возможно использовать на моих проектах и которая хоть немного что-то улучшает/упрощает — я начинаю ей пользоваться. Даже если она экономит мне жалкие 5 минут в день.


                                Мне кажется, здесь вина именно R#

                                Не исключаю такой возможности. Но я рассуждаю так: у меня есть на выбор два инструмента, дающих примерно одинаковые возможности. Первый работает плохо, второй хорошо. Очевидно, я выберу второй. И по существу мне без разницы, чья вина в том, что первый плох. Может, это криво написана студия. Может, решарпер криво интегрирован со студией. Может, решарпер сам по себе кривой. Мне это неинтересно, я пользуюсь ими в связке и смотрю как на единое целое.
                                Но учитывая, что VS + R# работает фигово, а IDEA + R# работает хорошо, я больше склоняюсь к тому, что что-то плохо в самой студии. Может, я и неправ.


                                Единственное, чего мне сейчас недостает в райдере — сравнимого со студией (особенно при использовании OzCode) дебаггера. В райдере он менее удобен и функционален, и пока еще там есть феерические баги.

                                • –1
                                  Согласен про это:
                                  билд, юнит-тесты (в студии это есть, но неудобно), поддержка JS, CSS, HTML с теми же самыми анализами
                                  Остальное есть или добавляется тривиальными анализаторами/расширениями.
                                  я вот люблю выжимать из инструментов все, на что они способны. Когда я вижу новую фичу, которую возможно использовать на моих проектах и которая хоть немного что-то улучшает/упрощает — я начинаю ей пользоваться. Даже если она экономит мне жалкие 5 минут в день.
                                  А вы не думали, что может быть тормоза этой фича у вас отнимают больше времени и нервов, чем экономит? Мне кажется, SWA именно к такому относится.
                                  • +2
                                    Остальное есть или добавляется тривиальными анализаторами/расширениями.

                                    Одного супер-решения я не видел, а искать и ставить условные 10 расширений, которые между собой еще и конфликтовать могут и где-то друг-друга дублируют, не особо хочется. Решарпер все же является единым продуктом. Да и вряд ли на некоторые фичи есть аналоги. Не стоит забывать о том, что решарпер пишут вроде уже 10 лет и там накоплена огромная куча всяких тулов.


                                    Но, конечно, я не спорю с тем, что кому-то будет достаточно голой студии и нескольких мелких экстеншнов. Тогда нет смысла ставить решарпер.


                                    А вы не думали, что может быть тормоза этой фича у вас отнимают больше времени и нервов, чем экономит? Мне кажется, SWA именно к такому относится.

                                    Это вполне возможно, фича тяжелая, но и полезная. Можно от нее отказаться и улучшить перформанс ценой потери части возможностей, а можно поставить райдер и сохранить фичу включенной. Я за второй вариант ) В райдере сейчас есть далеко не все, что дает решарпер, но мои потребности он покрывает. Ради остального я готов раз в неделю запустить студию.

                                    • –2
                                      Пара пакетов анализаторов на 95% покрывают рефакторинги решарпера. И они (анализаторы, основанные на Roslyn) гораздо стабильнее и качественнее, чем R#. На ум приходит explicit implementation, который R# издавна считает частью группы методов, и выдаёт предупреждения на shadowing и optional parameter.

                                      Странное у вас отношение, на самом деле. То вам нужна каждая-каждая фича, то «мои потребности он покрывает». Мне кажется, вы используете Rider, потому что это более новая, современная, вдохновляющая среда разработки, а не из-за производительности.
                                      • +1
                                        Пара пакетов анализаторов на 95% покрывают рефакторинги решарпера

                                        Я особо не интересовался этим, так что не готов дискутировать. Допускаю, что действительно для всего можно найти замену.


                                        То вам нужна каждая-каждая фича, то «мои потребности он покрывает».

                                        Каждая-каждая применимая. Мне не нужна поддержка JSX, например )
                                        Из того, чем я пользовался в студии на работе, мне не хватает разве что поддержки T4, красиво мигающих квадратиков в R# build и дебаггера. Зато получил крутую поддержку VCS и отсутствие тормозов.
                                        На личных проектах еще жалко continuous testing, но там я могу и студию использовать, т.к. проекты мелкие и не тормозит.


                                        потому что это более новая, современная, вдохновляющая среда разработки, а не из-за производительности.

                                        Не без этого. Доля вдохновления в этом тоже есть, но в основном все-таки тормоза достали. На мелких проектах действительно пользуюсь просто из энтузиазма, потому что в студии не тормозит и фич пока больше.

                    • +2
                      Прошу прощения, но ваши выводы как минимум спорные:
                      R# тормозит даже в Rider

                      Что такое тормозит? На каком железе? На какой ОС? Какие еще приложения рабоают параллельно?
                      новые версии R# работают медленнее

                      Откуда у вас такая инфорамция? Как вы это сравнивали? Как получить чистую производительность Reshaper'а?
                      чистый эффект от Rider нейтральный или отрицательный

                      Что такое чистый эффект? Для меня, например, эффект от Rider'а просто огромен:
                      1) наконец появился (появиться) конкурент студии;
                      2) Rider кросплатформенный. Для многих (для меня в частности) это просто праздник и возможность ( наконец-то) использовать Linux (Mac).
                      с памятью в студии лучше, чем когда-либо

                      К сожалению, не могу сказать про 2017 RC (буду ждать RTM), но в 2015 есть над чем еще работать. Хотя да, в Microsoft действительно серьезно занялись этой проблемой.

                      Ну и последний аргумент: Rider еще не готов и не выпущен. И как вы сами заметили, он все лучше и лучше. Тоже можно сказать и про студию 2017.
                      • –4
                        Что такое тормозит? На каком железе? На какой ОС? Какие еще приложения рабоают параллельно?
                        На любом. На любой. Не важно.
                        Откуда у вас такая инфорамция? Как вы это сравнивали? Как получить чистую производительность Reshaper'а?
                        Прочитайте комментарий заново.
                        Что такое чистый эффект?
                        Словарь
                        • +3
                          Что такое тормозит? На каком железе? На какой ОС? Какие еще приложения рабоают параллельно?
                          На любом. На любой. Не важно.

                          Еще раз пошу прощения, но это не инженерный ответ (подход). Возможно я ошибаюсь, но у меня сложилось впечатление, что вам Resharper просто не нравиться и(или) доставляет дискомфорт. Может ну его? Тем более, похоже, студия вас полностью устраивает.
                          Откуда у вас такая информация? Как вы это сравнивали? Как получить чистую производительность Resharper'а?
                          Прочитайте комментарий заново.

                          Прочитал. Извините, но это даже не намек на тестирование. И опять же, крайне интересно узнать как вы смогли измерить «чистую» производительность именно Resharper'а.
                          • 0
                            Всё-таки прочитайте мой комментарий. Целиком. Внимательно. Там есть ссылки на источники для ленивых. В этих источниках куча подтверждений моих слов о том, что R# тормозит на абсолютно любом железе.

                            Производительность конкретно R# измеряется достаточно просто – по сравнению с ним, влияние других компонентов на производительность пренебрежимо мало. То есть, производительность всего пакета стремится к производительности решарпера и в утрированном случае ему равна.

                            А он R# в VS 2017 я уже отказался.
                            • +1
                              Всё-таки прочитайте мой комментарий. Целиком. Внимательно. Там есть ссылки на источники для ленивых. В этих источниках куча подтверждений моих слов о том, что R# тормозит на абсолютно любом железе.

                              Перечитал ваш комментарий (целиком и предельно внимательно). Перечитал все по ссылкам. Прошу прощения, но не нашел подтверждение ваших слов про «абсолютно». Мой опыт использования R# (> 4 лет) на разном железе и разных проектах говорит об обратном. Да, без сомнения, «голая» студия часто «быстрее». Но будь она таким отличным инструментом, кто бы стал покупать и использовать R#?

                              Кстати, вы не могли не обратить внимание, что подавляющее большинство жалоб на R# (по ссылкам) именно на комбинацию VS 2105 + R#. И, к тому же, есть комментарии что на VS 2013, 2012 + R# все отлично. На мой взгляд, это именно то о чем говорил Андрей и спрашивал Алексей: студия разбухает и решарперу меньше места для «маневров» + конфликты с Roslyn'ом.

                              Производительность конкретно R# измеряется достаточно просто – по сравнению с ним, влияние других компонентов на производительность пренебрежимо мало. То есть, производительность всего пакета стремится к производительности решарпера и в утрированном случае ему равна.

                              Не согласен с вами. Особенно если рассматривать VS 2015 + Roslyn. А студия у вас выходит совсем уж идеальной и невесомой. Если бы не был с ней «знаком» 14 лет и 7 (вроде) релизов, может бы и поверил :).

                              А он R# в VS 2017 я уже отказался.

                              Рад за вас. Действительно. Обязательно гляну сам: скорее всего просто срабатывает старая привычка не использовать продукты MS до первого SP1.
                              • –1
                                Из всех ссылок только одна (последняя) из шести говорит о том, что R# медленный в 2015, не упоминаю предыдущие версии. Get your facts straight. И это соответствует моему опыту и наблюдениям. В моей компании у всех 2013, и все согласны с тем, что с R# работать очень сложно.
                                • 0
                                  Жаль это слышать. Надеюсь переход на VS 2017 решит ваши проблемы.

                                  Хотя опять же, если VS 2013 настолько хороша, то чего вы мучаетесь и используете R#? Выходит вас или заставляют (не хочу в это верить), или таки вы о чем-то умалчиваете и решарпер решает какие-то ваши (похоже весьма специфичные) задачи и «проблемы» с производительностью просто плата за эти «плюшки».
              • +4

                к сожалению когда встраиваешь R# очень тяжело оценить производительность.
                ибо мало того что становится два анализатора кода, так они еще и толкаются внутри одного процесса.
                (то есть идут не только издержки R#)


                на практике для себя я отказался от R# после выхода VS2015, написал пару рефакторингов, которых не хватало.
                все летает, меня устраивает.
                может я просто не ЦА R#, кто знает.

                • 0

                  — дубль ---

                • +4

                  @DreamWalker какой процент кода написан на Kotlin в Rider?

                  • +1

                    Вся логика на фронтэнде (там где мы интегрируемся с IDEA) написана на Kotlin на 100%. Бэкэнд (R#) пишется по понятным причинам на C#.

                  • +4
                    DreamWalker, огромное спасибо и успехов в пилении замечательного продукта!
                    От себя — очень очень хочу F#
                    • +2

                      Спасибо, с каждым новым днём стараемся делать Rider всё лучше и лучше. =)


                      От себя — очень очень хочу F#

                      Думаем над этим, но это не очень просто.

                      • +1
                        Могу себе представить коль скоро в R# так и не сделали. Что ж, жаль, если не состоится. Ибо всё, что вне VS под F# на уровне пионэрских поделоок, а VS смертельно утомила. Будем дальше завидовать сишарповцам))
                    • +1
                      Нам осталось сделать не так много.

                      отсутствует поддержка database project, чёт у меня есть предположение, что для их поддержки надо «много всего» )
                      • 0
                        Я правильно понимаю, что проблема в том, что у вас не открывается ранее созданный в студии SQL Server Database Project?
                        • 0
                          ну как, он вроде «открывается». Но под поддержкой я имею в виду:
                          — невозможно создать дб проект
                          — невозможно сделать локальный паблиш
                          — нет поддержки добавления новых объектов («Table», «View» и т.п.)
                          — не работает навигация по коду
                          Короче, проще перечислить, что работает:
                          1) открыть файл
                          • 0
                            Спасибо, обязательно посмотрим на это в обозримом будущем.

                            Живой sample был бы очень кстати — если вдруг вы знаете такого рода открытые проекты на гитхабе, будем благодарны за ссылку.
                            • 0
                              в открытых не видел. Это скорее из области сурового энтерпрайза ) Хотя, слышал о совсем запущенных случаях, когда специально обученные админы запускают самописные скрипты на живой базе, чтобы применить изменения…
                      • 0
                        DreamWalker
                        Видели эту статью?
                        http://mattwarren.org/2016/11/23/open-source-net-2-years-later/
                        • +2

                          Да, видел. Кстати говоря, Matt Warren (автор статьи) — один из разработчиков BenchmarkDotNet.

                        • 0
                          Он работает внутри процесса, и это большая проблема, потому что год 2016-й, а Visual Studio — всё ещё 32-битный процесс

                          возможно задам глупый вопрос, а почему не вынести свои потоки в отдельный процесс и организовать межпроцессное взаимодействие?
                          • 0
                            потому что это породит серьезный межпроцессный трафик, который надо будет минимизировать. Это наверняка делается, но занимает некоторое количество времени.
                          • +1
                            Я думаю, что вы и сами заметили, но на всякий случай скажу: офигенно закосяченное освещение, причём на Андрее, с этим надо что-то делать, оставляет негативное впечатление.

                            В целом — хорошее интервью.
                            • 0
                              «Я его слепила из того, что было!»
                              • 0

                                Мне, наоборот, непонятно зачем вообще изображение. Вся информация звуком :)

                            • +3
                              На мой взгляд, интересное интервью. Спасибо. И, конечно, отдельное спасибо за Rider. Я уверен, что наличие конкуренции пойдет на пользу как всей экосистеме .NET, так и MS Visual Studio.
                            • +2
                              Хотелось бы поправить про Xamarin. Не нем очень даже можно писать «топовые» приложения. UI можно делать абсолютно нативный. Единственная проблема с этим, нет множества популярных UI библиотек. Но их можно биндить и часто это помогает. Скорость же работы опять же «нативная». А в некоторых случая лучше чем у «родного окружения».
                              • 0
                                Ну в кровавом энтерпрайзе есть большое предубеждение против Mono, уж не знаю с чем это связано и насколько объективно. Многие серьёзные конторы просто отказываются признавать его годной платформой для прода
                                • 0

                                  Зависит. Прежде всего зависит от потребностей конторы и готовности самим фиксить баги в моно. Rider бежит поверх Mono, бежит нормально. Проблемы есть, на них приходится тратить определённое время, но при желании на этом рантайме можно разрабатывать вполне серьёзные приложения.

                                • 0

                                  Спасибо за дополнение! Рад, что у вас нет проблем со скоростью и интерфейсом, Xamarin действительно очень прокачался за последнее время. Но хотелось бы сказать, что потребности у народа разные: я постоянно общаюсь с Xamarin-разработчиками, отзывы о платформе у всех различные. Очень здорово, что на рынке имеется подобный инструмент, но судя по всему направления для развития всё ещё есть. =)

                                • +2
                                  DreamWalker
                                  Интересует вопрос версий Rider: будет ли аналог Community как у IntelliJ IDEA?
                                  • +1

                                    Ещё не решили. Сначала нужно дописать продукт, а потом будем думать про лицензирование. =)

                                    • 0
                                      Ясно, спасибо. Прошу прощения, что продолжаю эту тему, но на мой взгляд это важно. Уж очень заманчиво выглядит будущее .NET без привязки к Windows и VS. А наличие бесплатной, пусть и слегка :) урезаной, версии Rider явно понизит порог входа в такую среду для интересующихся (в первую очередь студентов) и желающих попробовать. Ну и опять же, нужна конкуренция VS Community.
                                      • +2
                                        Предложение про Community разумное, но нам нужно время, чтобы оценить рынок. Это не вопрос первой версии.

                                        Что касается студентов, то им в любом случае полагается бесплатная подписка на All Products, куда Rider несомненно войдет.
                                        • +3
                                          Спасибо за ответ. Успехов вам и Rider'у.
                                  • 0
                                    Пока единственное, что останавливает от использования Rider — серые аргументы в методах при использовании Dracula + VS Theme. А Resharper приучил удалять такие, как неиспользуемые, но они используются и это дико раздражает.

                                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                  Самое читаемое