Производительность
Скорость индексации
Индексация на данный момент — одно из самых проблемных мест с производительностью наших IDE. Мы планируем подойти к ее решению с нескольких направлений.
Во-первых, мы планируем поддержать готовые фрагменты индекса. Теперь вместо того, чтобы каждая копия IntelliJ IDEA заново индексировала класс java.lang.String, мы сможем предоставить для скачивания готовый фрагмент индекса для JDK, который можно будет переиспользовать без дополнительных затрат CPU. Помимо JDK, мы изучаем возможность предоставлять готовые фрагменты индекса для библиотек из Maven Central, а также для интерпретаторов и пакетов в других IDE. Мы также хотели бы позволять командам и организациям использовать готовые фрагменты индекса для кода своих проектов, но у нас пока нет на этот счет конкретных планов.
Во-вторых, мы планируем сделать индексирование менее мешающим работе, сделав более широкий набор действий доступными во время индексации.
В-третьих, мы планируем обнаруживать аномалии индексации и уведомлять пользователей о них. Аномалии включают в себя файлы, которые индексируются слишком долго или слишком часто, а также перестроения индексов, вызванные исключениями. Наша цель — предлагать конкретные шаги, позволяющие решить проблему и улучшить производительность IDE.
Ну и наконец, мы продолжаем заниматься старой доброй оптимизацией — добиваться того, чтобы в индексы не попадали ненужные данные, а процесс индексации использовал минимально возможные ресурсы.
Новая модель многопоточного доступа к структурам данных IDE
Еще одно проблемное место в производительности — это «замерзание» пользовательского интерфейса. В этом году мы построили инфраструктуру для сбора информации о таких проблемах. Это позволило нам решить многие из них (например, мы создали и задействовали стандартный механизм асинхронной обработки событий от файловой системы). В следующем году мы планируем шагнуть дальше и вынести операции, модифицирующие структуры данных из UI потока.
На заре существования IntelliJ IDEA было принято архитектурное решение, требующее выполнять все модификации структур данных IDE из UI потока. Это включает в себя и базовые действия (вставка символа в документ), и длительные операции (переименование метода, вызываемого из многих мест). Такая архитектура сильно упрощает модель программирования, но очевидным образом ухудшает отзывчивость интерфейса.
За прошедшие годы мы как-то научились обходить ограничения этой модели, в основном за счет того, чтобы разделять длительные операции на фоновое вычисление необходимых изменений и по возможности быстрое применение этих изменений в UI потоке. Идеальным решением было бы вообще убрать требование делать что-то в UI потоке, но до сих пор мы не понимали, как можно этого достичь без переписывания всего кода IDE и сторонних плагинов. Теперь у нас есть вариант архитектуры, который позволяет постепенно мигрировать код на новую модель многопоточности, и мы начинаем работу над его реализацией.
В течение следующего года мы планируем добавлять поддержку новой модели многопоточности в ключевые UI-компоненты и API платформы. Когда мы увидим, что новая модель работает стабильно и дает ожидаемые улучшения, мы перейдем на нее и таким образом избавимся от основного источника проблем с зависанием UI.
Загрузка и выгрузка плагинов без рестарта
Первые результаты работы в этом направлении попали уже в релиз 2019.3, который позволяет устанавливать плагины цветовых тем и клавиатурных раскладок без перезагрузки. В следующей версии мы планируем расширить эту поддержку на все типы плагинов. Мы будем поддерживать загрузку и выгрузку без рестарта для большей части наших собственных плагинов, и мы опубликовали инструкции по поддержке для сторонних плагинописателей.
На данном этапе основным преимуществом станет безболезненное обновление плагинов, не требующее перезагрузки. В дальнейшем мы планируем достичь более интересной цели: IDE, которая автоматически загружает только нужный набор плагинов для каждого проекта, который вы в ней открываете. Используете Spring — загружается Spring плагин, нужен Angular — плагин к вашим услугам. Неиспользуемые плагины будут автоматически отключены и не будут расходовать ресурсы и занимать место в интерфейсе.
Поддержка сценариев разработки
Совместное редактирование
Запрос на поддержку совместного редактирования собрал больше всего голосов в нашем issue tracker, и мы рады объявить, что мы работаем над этой функциональностью. В нашем текущем подходе выделяется «главная» IDE, работающая на той машине, где хранится редактируемый исходный код, и «тонкие клиенты», которые могут подключаться к главной IDE и не должны иметь свою копию исходного кода. Каждый из подключенных клиентов имеет свое состояние (набор открытых файлов, позицию каретки, список вариантов автодополнения и т.д.), но при желании может и «следовать» за другим пользователем.
«Тонкие клиенты» будут иметь доступ к базовой функциональности IDE, такой как навигация, автодополнение и отладка, но не будут поддерживать 100% имеющихся функций. (Например, работа с системами контроля версий не входит в текущий план на первоначальный релиз.) Точный набор поддерживаемых функций на данный момент не определен, и мы не готовы отвечать на вопросы про то, что и когда будет поддержано.
Поддержка совместного редактирования основана на протоколе Rider, поэтому скорее всего она изначально появится в этом продукте и потом распространится на другие IDE. В любом случае, в релизе IntelliJ IDEA 2020.1 ничего из этого не появится — это план на более длительный срок.
Кроме того, нужно заметить, что, поскольку текущая реализация совместного редактирования использует наш собственный протокол, она не будет совместима с инструментами не от JetBrains.
Подход «тонких клиентов» может быть полезен и для других сценариев, таких как перенос бэкэнда IDE в облако, но мы пока что не готовы анонсировать какие-либо планы в этой области.
Поддержка запуска в облаке
Уже довольно давно многие наши продукты поддерживают запуск и отладку кода на удаленных компьютерах и в контейнерах. К сожалению, эта поддержка почти везде реализована по-своему, и даже такие универсальные фичи, как поддержка Docker, выглядят в разных IDE по-разному.
Теперь мы добавляем на уровне платформы концепцию «окружения для выполнения», которое дает способ копировать файлы в него или из него, а также запускать в нем процессы. В IntelliJ IDEA 2020.1 мы поддержим выполнение на локальной машине, в Docker-контейнере и через ssh-соединение. Выбирать окружение для выполнения можно будет в конфигурациях запуска для Java и Go.
В последующих релизах мы планируем унифицировать поддержку Docker и удалённых интерпретаторов на основании новой архитектуры. Кроме того, мы предложим улучшенную интеграцию с облаками, чтобы вы могли запускать процесс на новой виртуальной машине в облаке, не указывая конкретный адрес машины, к которой надо подключиться.
Новый дизайн проектной модели
Проектная модель — это то, как IDE представляет структуру вашего проекта: какие файлы к нему относятся, как они друг от друга зависят, какие библиотеки используются, и т.д. Проектная модель IntelliJ IDEA хорошо нам послужила за прошедшие годы, но мы начали упираться в ее ограничения. Во-первых, она не позволяет произвольным образом смешивать проекты разных типов. Вы можете открыть проект Xcode в AppCode или солюшен Visual Studio в Rider, но нет такой IDE, в которой вы могли бы открыть в одном окне проекты Gradle и Xcode. Во-вторых, она работает на уровне каталогов и не позволяет разным файлам в одном каталоге иметь разные зависимости. Это усложняет интеграцию с билд-системами типа Bazel и создает проблемы в других сценариях.
Новая проектная модель, которую мы называем workspace model, убирает эти ограничения. Она дает и другие преимущества, такие как более быстрое открытие проекта, более гладкая синхронизация с Maven и Gradle, и более удобная модель программирования.
Мы начнем с того, чтобы перевести реализацию существующих функций на новую проектную модель, и затем, когда все будет работать стабильно, начнем добавлять новые функции, такие как открытие набора проектов разных типов в одном окне IDE.
Резюме
То, о чем мы сейчас рассказали — только малая часть того, над чем работает команда, и мы планируем рассказать больше о наших планах после праздников. Конечно же, все эти планы могут измениться, и очень может быть, что что-то из этого рассказа никогда не попадёт в релиз, зато мы сделаем для вас другие крутые улучшения.
Мы будем рады услышать от вас обратную связь. Кроме того, приглашаем вас принять участие в нашей Early Access Program, которая даст вам возможность попробовать какие-то из этих возможностей до того, как они попадут в официальный релиз.
Комментарии (21)
ShashkovS
20.12.2019 22:58например, мы создали и задействовали стандартный механизм асинхронной обработки событий от файловой системы
А вот скажите, это у одного меня такая проблема, или это общее:
иногда я хочу открыть какой-нибудь проект или файл. Для этого открывается кастомное IntelliJ-окно со структурой папок-файлов. Но оно открывается несколько минут. И даже если я в точности знаю путь к файлу, или тупо передумал, оно блокирует UI и пару минут что-то сканирует. Да, у меня там папка с проектами и там фигова туча подпапок и файлов. Но не надо туда внутрь лезть до того, как явно попросят.
Могу гифку сделать.Vest
21.12.2019 12:41… или хотя бы несколько thread dumps… к гифке будут полезны…
ShashkovS
21.12.2019 22:05
Неправильно написал. UI не блокирует. Не даёт ничего открыть (даже если знаешь точный путь) или сменить текущую папку на другую, пока не подождёшь минутку-другую. Окно можно закрыть и открыть заново, но снова придётся ждать.Vest
21.12.2019 23:00теперь лучше, а можно thread dump? Может быть у вас антивирус крутится и препятствует обращению к файлам.
Maccimo
22.12.2019 05:22Не у одного.
Быстро открыть диалог, вставить путь из буфера обмена и сразу нажать на «ОК» — сейчас это что-то из области фантастики.
Всегда присутствует дополнительный этап «мы будем долго шуршать диском и строить никому не нужное дерево».
Если сильно не повезёт, то случается ситуация «что-то я в своём дереве такого пути не вижу, идите лесом». Пока диалог не найдёт введённый путь в своём дереве, через «ОК» его закрыть нельзя, только через «Отмену».
FruTb
21.12.2019 09:25-1> Во-первых, мы планируем поддержать готовые фрагменты индекса. Теперь вместо того, чтобы каждая копия IntelliJ IDEA заново индексировала класс java.lang.String, мы сможем предоставить для скачивания готовый фрагмент индекса для JDK, который можно будет переиспользовать без дополнительных затрат CPU
может стоить глянуть в сторону того как bazel свой расаредеоенный кеш организует?
puyol_dev2
21.12.2019 16:41С индексацией у вас и правда какая-то хрень. Даже крошечный проект индексируется несколько десятков секунд
MIKEk8
23.12.2019 13:51Теперь вместо того, чтобы каждая копия IntelliJ IDEA заново индексировала класс java.lang.String, мы сможем предоставить для скачивания готовый фрагмент индекса для JDK
То есть вне зависимости от размера вашего проекта IDEA индексирует и стандартные библиотеки, что скорей всего и занимает эти десятки секунд.
Marahal
22.12.2019 11:02У меня есть предложения:
1. У вас в планах окружение для выполнения. Это очень хорошо. Можно ли еще добавить туда возможность, чтобы исходники лежали на сервере и сборка и компиляция могла быть тоже на сервере. То есть было бы «Окружение для сборки и выполнения». Или добавить «окружение для сборки». Чтобы собрать часто приходится настраивать окружение, если работаешь с разных компьютеров. Удобно настроить его на сервере, положить туда проект, а работать с ним с IDE с компьютера дома или на работе или коллега может туда зайти и т.д.
2. Многие хотят быстрый запуск. Сейчас появилась концепция compile time инициализации, то есть когда объекты инициализируются при компиляции, а во время выполнения грузится сразу область памяти целиком. Например, запуск Quarkus native приложения может занимать 0.001 секунды. Для компиляции используется GraalVM. Тут будет проблема с плагинами, но и для нее есть варианты решения. Мне кажется, направление перспективное.
Большое спасибо за внимание.yole Автор
23.12.2019 16:29Про поддержку работы с проектами, где исходники лежат только на сервере, мы пока не готовы ничего анонсировать. Понятие «окружение для сборки» имеет смысл далеко не для всех проектов — сборка большинства Java проектов не зависит от окружения, а для Ruby/Python/PHP собирать часто вообще ничего не надо — поэтому у нас нет планов вводить такое понятие на уровне платформы.
На GraalVM мы конечно смотрим, но пока что мы не видим такого соотношения cost/benefit, которое оправдывало бы серьезные в него вложения.
Blekel
22.12.2019 20:52Выглядит довольно хорошо. Желаю удачи в реализации планов в новом году!
И поменьше CPU Usage в IDE тоже. )
Было бы здорово увидеть подобный план от команды ktor.
А то на бумаге выглядит хорошо (только дока простовата), а при переписывании относительно небольшого проекта со Spring Boot на ktor — испытываешь кучу проблем на стадии мелочей, которых после такого срока разработки, казалось бы, — уже не должно быть.
Например, фичи поддержки Tomcat и Thymeleaf по-отдельности реализованы, но вот вместе это все работает пока на честном слове:
- приходится хардкодить контекст приложения во вью, если не делать мэппинг на фронте на отдельный поддомен — потому что в объекте фичи Thymeleaf контекст создается тупо через Context(), который не совместим с IWebContext;
- основной сервлет падает при редеплое war в локальный Tomcat;
- и т.п.
А так вообще, подход более явного application setup — очень хорош относительно других микрофреймворков.
cy6erGn0m
23.12.2019 19:00Откройте, пожалуйста, тикеты, описывающие эти проблемы в github.com/ktorio/ktor/issues. Все предложения и пожелания есть смысл описывать там.
Подробный план на данный момент нигде не опубликован, однако, основные планы вокруг коммонизации (Kotlin Multiplatform) сервера и более тесной интеграции с kotlinx.serialization.
e_v_genius
23.12.2019 16:09Хочу просто поблагодарить за лучшую, с моей точки зрения, IDE для разработки. Большое вам спасибо, ребята!
xRay
С Java перепишете IntelliJ Platform на C++, Rust?
germn
C++, Rust — зачем такие медленные языки? Надо сразу на ассемблере переписывать.
xRay
Это была шутка