Visual Studio Code отнимает 13% ресурсов CPU из-за мерцания курсора



    Забавная проблема #22900 на этой неделе привлекла особое внимание пользователей Github.

    Подробное описание проблемы — в репозитории редактора кода Visual Studio Code (vscode). Open source разработчик Джо Лисс (Jo Liss) известна как создатель Broccoli и других свободных библиотек. На странице проекта она обратила внимание, что Visual Studio Code использует 13% вычислительных ресурсов процессора, если окно находится в фокусе. Из-за этого впустую расходуется заряд аккумулятора на ноутбуке. Что могло бы быть причиной столь странного поведения программы?

    Джо Лисс предположила, что активность CPU связана с рендерингом мерцания курсора — изменение состояния курсора происходит два раза в секунду, то есть каждые 500 мс (2 fps).

    Для воспроизведения проблемы следует проделать следующие шаги:

    1. Закрыть все окна Visual Studio Code.
    2. Открыть новое окно (File → New Window).
    3. Открыть новую вкладку с пустым файлом (File → New Tab). Курсор мигает.
    4. В мониторе ресурсов вы увидите ненулевое потребление вычислительных ресурсов (13% на слабом ноутбуке с OS X, около 5-7% на мощном GNOME Shell с Wayland (Ivy Bridge Graphics)).
    5. Переключиться на окно другого приложения (Cmd+Tab). Курсор больше не виден.
    6. Потребление CPU программой Visual Studio Code снижается практически до нуля.

    Ему кому-то нужно, вот таймлайн записи в Developer Tools: TimelineRawData-20170321T114212.json.zip (см. скриншот выше).

    Если приблизить на один фрейм, то можно заметить, что несмотря на частоту мерцания 2 fps, основной поток выполняет некую работу на 60 fps, то есть рендерит что-то каждые 16 мс.



    Если ещё больше приблизить, то становится видна конкретная большая работа, которую выполняет рендеринг курсора на 60 кадрах/с. Это периодические циклы «Update Layer Tree» / «Paint» / «Composite Layers», то есть обновление дерева слоёв



    Разработчик обращает внимание, что в других приложениях macOS Sierra 10.12.3, в том числе Chrome и TextEdit, курсор мерцает без заметного потребления ресурсов CPU.

    Пользователи редактора Visual Studio Code могут отключить мерцание курсора в программе. В этом случае потребление CPU снижается до 0%. Циклы "Update Layer Tree" / "Paint" / "Composite Layers" всё равно работают, но только каждые 500 мс, а не каждые 16 мс.

    "editor.cursorBlinking": "solid"

    Этот забавный глюк в Visual Studio Code напоминает классическую проблему с тормозным индикатором в npm. В версии npm 3.5.2 при включенном индикаторе хода выполнения операции эта операция выполнялась примерно на 50% медленнее, чем без индикатора.

    $ rm -r node_modules
    $ npm set progress=false
    $ time npm install
    npm install  19.91s user 2.66s system 71% cpu 31.667 total
    
    $ rm -r node_modules
    $ npm set progress=true
    $ time npm install
    npm install  33.26s user 3.19s system 74% cpu 48.733 total

    В чём причина


    Конечно, потребление ресурсов CPU при мерцании курсора имеет совсем иные причины, чем замедление npm с активным индикатором прогресса. О причинах проблем с курсором можно догадаться, если посмотреть на почти такой же баг с анимацией ключевого кадра CSS в браузере Chrome. Там разработчики пишут, что в JavaScript мерцающий курсор отнимает нормальные 1,2% ресурсов CPU, а в CSS почему-то в 6 раз больше, то есть 7-8%.

    Код вроде корректный:

    @keyframes monaco-cursor-blink {
    	50% {
    		opacity: 0;
    	}
    	100% {
    		opacity: 1;
    	}
    }
    
    .cursor-blink {
    	animation: monaco-cursor-blink 1s step-start 0s infinite;
    }

    Но проблема в том, что движок Chromium принудительно переводит эту анимацию в 60 fps, заставляя выполнять работу каждые 16 мс.

    Так вот, редактор Visual Studio Code, очевидно, использует самый логичный подход для реализации функции мерцающего курсора: это функция step с анимацией ключевого кадра CSS. А этот баг в Chromium до сих пор не исправили полностью, хотя он тянется уже больше двух лет. Так что Chrome осуществляет полный цикл рендеринга каждые 16 мс, как и положено для 60 кадров в секунду. Возможно, теперешнее обсуждение позволит привлечь внимание к старому багу — и у разработчиков наконец-то дойдут руки до него.

    Разработчики Visual Studio Code признались, что изначально эта функция была реализована на JavaScript, но примерно год назад они переключились на CSS. В текущей реализации если окно не в фокусе, то анимация деактивируется и излишнего потребления ресурсов процессора не происходит, но вот с активным окном действительно проблема. Разработчики считают, что в такой ситуации есть смысл вернуться с CSS обратно на JS.

    Коллеги советуют подумать также над тем, чтобы реализовать курсор в виде анимированного gif'а. Можно генерировать такой файл автоматически, в зависимости от цветового оформления редактора. Правда, здесь может быть сложность с зуммированием: всё-таки растровая графика станет расплывчатой при зуммировании.

    Но в конце концов разработчики из Microsoft всё-таки решили вернуться на старый добрый JS-метод setInterval для мерцания курсора — и потребление CPU сразу снизилось в несколько раз.
    Метки:
    Поделиться публикацией
    Похожие публикации
    Комментарии 130
    • +9
      13% — это, кстати, подоходный налог 100% одного потока из восьми.
      • +3
        Они меряли на MacOS а там Activity Monitor сообщает загрузку одного ядра. Т.е. процесс в AM может показывать и 200% если два ядра занимает.

        Т.е. если привести это число к методике Windows (100% — загрузка всех ядер) то будет 1.5-3% что в общем согласуется с реальными цифрами.

        Вот цифры на W10:

        image

        (там правда VS Code создает 6 процессов на это бедное окно, показан только rendering process)

        Вот для сравнения Sciter c тем же Skia backend который использует Электрон.

        Используется аналогичная по сложности структура экрана — редактор с подсветкой.

        image

        И для сравнения тот-же Sciter но c Direct2D backend:

        image
    • +28
      Коллеги советуют подумать также над тем, чтобы реализовать курсор в виде анимированного gif'а

      Дожили — сделать мерцание курсора с помощью рендеринга gif'а, теперь приводится как хорошее и быстрое решение.
      • +7
        Наверное, придумать другой способ нарисовать мигающую полосочку на компьютере, делающем несколько миллиардов операций в секунду, нельзя. Надо или весь интерфейс перерисовывать вместе с ним, или гифку.
      • +14

        Когда мне опять будут мыть мозги веб-приложениями, SPA, Electron'ом и прочей ересью, буду в ответ кидать ссылку на этот пост.

        • +2
          Только ещё для полноты картины нужно вот этот ответ приводить:
          If instead you are suggesting a fully native, non web stack based application: when you traverse the likely needs of a heavily themed, fully DPI independent, cross-platform application like VSCode, odds are that a non-native cursor substitute would be needed regardless.
          • –6

            Чего прям сразу fully native? Вон Eclipse и heavily themed, и cross-platform, и все остальное, и работает нормально.

            • +3
              Бггг, Eclipse на чем-нибудь типа Атома — это стыд и боль, перешел с TrueStudio на EmBitz исключительно из-за адских тормозов первого…
              • +7
                С каких это пор Eclipse работает нормально?
                • 0

                  У меня что на 10-ке, что на Ubuntu все работает нормально. У вас работает не нормально?

                  • +1
                    Intel Core i9 Extreme Edition, 256 Гб RAM, NVMe SSD? Ну да, тормозить почти не будет…
                    • 0

                      Core i3 и 4 Гб RAM, на Ubuntu — i5 10-го года и 2 Гб. Что я делаю не так?

                      • +2
                        У вас просто болевой порог высокий.
                        • 0

                          Atom на Ubuntu работал довольно уныло, хотя это даже не IDE.

                  • 0
                    приведите критерии нормальности
              • +7

                Ситуация комичная конечно, но вот буквально вчера я отказался от WebStorm в пользу VS Code по причине… меньшего потребления ресурсов и лучшей стабильности последнего. Все очень неоднозначно, и огульно экстраполировать что-то одно на всю экосистему — большая ошибка, особенно для инженера.

                • 0
                  экстраполировать что-то одно на всю экосистему — большая ошибка, особенно для инженера.

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

                  • +2
                    Которую совершаете и вы тоже

                    Я где-то заявлял, что все не-веб технологии — ересь? Вроде нет.

                    • –3

                      Нуок, но лично я заявляю, что веб-технологии ересь, поюзав всякие Atom, Skype, Slack и десяток-другой сайтов SPA, особенно на китайских мобилках.)

              • +3
                Даже если это и баг, что курсор рендерится 60 фпс, то занятие им 13% процессора это ужас.
                • +1
                  Я подозреваю, что существует какой-то обратный закон мура. Чем производительнее становятся компьютеры, тем неэффективнее становятся программы.
                  • 0
                    что существует какой-то обратный закон мура
                    Тут не совсем закон (в смысле того, что его просто так не выразить числами), но зависимость. Только есть ещё третий фактор — полная стоимость разработки. Грубо говоря, можно писать программы с той же эффективностью, что и в эпоху динозавров. Но это потребует намного более дорогих специалистов, больше времени на отладку и оптимизацию, более тщательного планирования разработки и т.д.

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

                    • +1
                      Грубо говоря, можно писать программы с той же эффективностью, что и в эпоху динозавров. Но это потребует намного более дорогих специалистов, больше времени на отладку и оптимизацию, более тщательного планирования разработки

                      Я не уверен, что намного. Многие из нас жили в эпоху динозавров и писали те самые программы, которые как-то ухитрялись работать, о боже, на 100МГц одноядерных Пентиумах с 16 Мб памяти (мои наручные часы с четырехядерным процем презрительно смотрят на эти характеристики). При этом работали зачастую шустрее, чем их аналоги сейчас. А главное, если иметь в виду не всякие там тяжелые вычисления, то и задачи решали примерно такие же. При этом какого-то качественного скачка в скорости разработки нового функционала с тех пор не произошло. Произошли изменения в подходе. Если, например, разработчик 1990-х хранил параметры приложения в ini-файле, и использовал для работы с ними нехитрый класс-обёртку, то разработчик 2010-х будет использовать xml-файл, а для работы с ним возьмет многомегабайтный парсер, который там будет уметь работать с коллекциями, поддерживать DOM, SAX, схемы документа, XML-трансформацию и много-много других в каком-то случае полезных вещей, но вот этот экскаватор Caterpillar, дети, нам будет лепить пасочки монстр будет использоваться для чтения десятка строк из текстового файла. При том, что и в 1990-х, и сейчас время, затраченное на решение этй задачи, будет примерно одинаковым. И так сплошь и рядом.
                      • 0
                        Я не уверен, что намного
                        Именно что намного. Тут есть такой фактор как «количество людей, занятых разработкой в целом». Ещё 25 лет назад народ задумался о том, что постоянная стрельба в ногу за счет ручного управления памятью и прямого доступа к железу выходит слишком дорогой для энтерпрайза, а способа массово научить миллионы потребных разработчиков не стрелять себе в эти самые ноги на горизонте не видно. Причем получаемые решения страдали рядом фатальных недостатков — они были «неуниверсально оптимизированы» — вспомним хотя бы аттракционы «на каком видеоускорителе эта игра идет быстрее и не падает», и крайне неадаптированы к режиму «а сейчас мы этого гуру дорогого выгоним и посадим десяток людей с аутсорса» ввиду плохой документированности и общей требовательности к уровню понимания происходящего.

                        В итоге с одной стороны пошла тенденция загонять все и вся в сандбоксы разной степени виртуализированности, убирая прямой доступ к железу. С другой стороны, пошла тенденция под названием «да возьми библиотечную функцию — и не парься». Широко распространенные языки обзавелись богатейшими стандартными библиотеками, которые позволяют программировать прикладные задачи на уровне сборки кирпичиков из лего. Отдельно на это все натянули практически бесплатную кроссплатформенность на уровне этих самых библиотек, что позволяет нанимать на позицию «программиста под андроид или иос» человека, не совсем представляющего, как работает андроид или иос (и если кому-то кажется, что это ерунда, посмотрите, сколько прикладных виндоус-разработчиков могут описать как работает их операционка — хотя бы на уровне «что такое кольца защиты и почему Windows использует их два, а процессоры поддерживают четыре»).

                        И да, скорость разработки для продукта, который пишется на колене за несколько месяцев — это очень важно. Вот мне сейчас нужно написать несколько скриптов, вытаскивающих данные из багтрекера для аналитики. Написать мне их надо до конца дня. И хоть у багтрекера есть родной рест-апи, я все равно возьму библиотеку, оборачивающую этот рест-апи, т.к. на выходе я получу уже распарсенные и разложенные по полям и аттрибутам объекты, мне не надо писать все обработчики исключений на каждый возможный чих и мне не надо собирать результаты пачки запросов в один.
                        • –1
                          посмотрите, сколько прикладных виндоус-разработчиков могут описать как работает их операционка — хотя бы на уровне «что такое кольца защиты и почему Windows использует их два, а процессоры поддерживают четыре»

                          Пишу на PHP, знаю и о кольцах, и о том, что используется только два кольта потому, что некоторые ранние архитектуры, на которых работало ядро NT, не поддерживает больше 2 колец. Что я делаю не так?
                          • 0
                            Что я делаю не так?
                            Вы-то персонально все делаете так. Но многие этим не заморачиваются, т.к. в их повседневной жизни им от этих знаний ни холодно, ни жарко — у них есть «их» окружение и выходить за его пределы они не особо стремятся.
                        • +1
                          Во времена 100МГц пентиума я сравнил одну и ту же(!) программу на basic, рисовавшую фигуру лиссажу для соотношения частот 79:80 на экране 320x200 между qbasic и basic на ZX Spectrum. В котором были какие-то единицы мегагерц на 8-ми битном процессоре, устаревшем уже тогда лет на 10-15, кажется. Пентиум был быстрее, но раза так в 4-5 вместо ожидаемых мной 20-30 — в нем же уже был FPU и PCI шина к видеокарте и вообще…
                      • +1
                        Это наверное мое больное место, но мне кажется, что неэффективность еще может быть связана с распространением неподходящих инструментов. Как в свое время появился PHP — совершенно непродуманный примитивный язык, но настолько простой, что любой мог начать на нем программировать. Помню, несколько раз брался что-то править в проектах, написанных на PHP, и волосы вставали дыбом.

                        Несколько лет назад возникло похожее движение — Node.js и иже с ним. «Давайте все писать на Javascript, который никогда для этого не был предназначен! А главное, что даже ничего не понимая в компьютерах и программировании, можно сляпать огромное красивое приложение!»

                        В итоге, то, что в примерах выглядело хорошо (красивый функциональный код, мгновенная реакция на действия пользователя), в реальной жизни превратилось в кошмарных едва ворочающихся монстров.
                    • +18
                      в JavaScript мерцающий курсор отнимает нормальные 1,2% ресурсов CPU

                      Нормальные? Т.е. всего 83 курсора сожрут современный процессор полностью?
                      А как курсоры мигали в 80-е и 90-е? На другие задачи, видимо, ресурсов уже не оставалось.
                      • –4
                        тогда использовали ардуино #sarcasm
                        • +3
                          Нет, основная часть этого времеи — не рендеринг курсора, а работа, общая для всех перерисовок. Посто мерцание курсора не даёт этим процессам «засыпать».
                          • –1
                            А зачем эта работа выполняется, если она явно не нужна? Because we can. Обычное рукожопие.
                          • +13
                            как курсоры мигали в 80-е и 90-е?

                            Были специальные курсорные сопроцессоры, а на мейнфреймах под это выделяли целые модули! Сейчас от этого ушли, в пользу программной эмуляции, но, видимо, зря.
                            • +4
                              Ну смех смехом, но в текстовом режиме (CGA/EGA) курсор действительно рисовался аппаратно как впрочем и шрифты.
                          • +7
                            Специально сверился с календарём. Нет не первое апреля…

                            Скажите, индустрии ПО крыш? Или еще можно спасти? (и индустрию, и честь процессора, которому не придется всю жизнь ишачить на курсор)
                            • +4
                              К сожалению, с ростом вычислительных мощностей, такое отношение к потреблению ресурсов становится скорее нормой, чем отклонением. Спасти ситуацию можно, создавая быстрый эффективный код, и принципиально отказавшись от присказки «моё рабочее время стоит дороже чем планка оперативки/более мощный процессор».
                              • +4
                                Можно подумать, это сам разработчик решает, что «его рабочее время стоит дороже чем планка оперативки». Это решает рынок в целом и его руководитель/заказчик в частности.
                                • –1
                                  Но говорят это почему-то именно разработчики. Зачастую, чтобы «сделать плохо» и «сделать хорошо» нужно одно и то же время — разница лишь в профессионализме разработчика. И хорошему разработчику хотя бы профессиональная гордость должна мешать делать плохо.
                                  • +1
                                    Хороший разработчик за свою работу берёт столько что часть заказчиков обращаются к плохим разработчикам.
                                    • +5

                                      Столкнувшись хоть раз со сколько-нибудь сложной системой — раз и навсегда понимаешь: "сделать хорошо" — невозможно. Всегда будет какой-то компромис, всегда "хорошо" будет только с какого-то одного ракурса. У хорошего разработчика не должно быть таких иллюзий. Это не значит, что все нужно делать абы как, это значит, что хороший разработчик должен уметь находить баланс и не абсолютизировать какой-то один аспект, будь то потребление ресурсов или что-то иное.

                                      • 0
                                        Сделать десктопное (десктопное, Карл!) приложение на HTML+JS это вообще за гранью добра и зла. Что помешало Microsoft сделать редактор кода используя более подходящие для этого языки и фреймворки? Ей-богу, это Web головного мозга какой-то…
                                        • +1
                                          Что помешало Microsoft сделать редактор кода используя более подходящие для этого языки и фреймворки?

                                          Может быть это потому, что HTML+JS — работает на огромном количестве платформ (включая ARM), и скорость разработки у этой связки довольно неплохая. И HTML+JS как-раз оказался «более подходящим для этого языком и фреймворком»
                                          Хотя нет, вы правы конечно, что там эти м*даки в MS понимают в создании приложений… Как обычно наверное какой-то джуниор предложил «А давайте на HTML писать», и все такие «А давайте!»
                                    • 0
                                      Можно подумать разработчик это новая форма рабского права, за которого все решает заказчик.
                                      • +1
                                        Я вас наверное удивлю, но любой наёмный работник это «новая форма рабского права, за которого все решает заказчик». Вы можете определять стоимость своего времени, но объём работы, как не крути, диктуется заказчиком.
                                      • +1
                                        Раньше была шутка, что разработчик программы, обслуживающей лампочку капслока, считает, что все ресурсы компьютера в его распоряжении.
                                        Сейчас это точно уже не шутка.
                                      • +2
                                        Но ведь в данном случае не нужен быстрый код
                                        Нужен просто код, работающий *логично*, черт возьми! ))
                                        Т.е. такой, который не перестраивает, и не перерисовывает всю матрёшку интрефейса при каждом жалком мигании жалкого курсорчика. Речь же совсем не о производительности.
                                    • +12
                                      Вот до чего довел Node.js головного мозга. К сожалению, все чаще вижу приложения на Electron. Да, все круто выглядит, только медленно работает, и отжирает половину ресурсов ноутбука. Особенно обидно, когда приложение имеет вспомогательный характер. Скоро дойдет до того, что часы в трее будут требовать не менее 4 Гб RAM и отъедать 15% CPU на отрисовывание секунд. :(
                                      • +11

                                        Вы только что описали схему работы значительной части modern ui приложений в восьмерке и десятке. 100 мегабайт ОЗУ на low-res приложение погоды, входящей в поставку Винды? Запросто. 25% от CPU? Как два пальца об асфальт. Очередь 5400 RPM диска на 3 секунды? Да каждый божий день.
                                        Ах да. Без более-менее быстрого GPU десятка (т.е. со стандартным VGA-драйвером) еще безбожно тормозит, отрисовывая интерфейс.

                                        • +2

                                          Особенно весело видеть, как какой-то слак отжирает полтора гигабайта рамы.

                                          • 0
                                            Ну не знаю, сильно зависит от разработчика. Тот же телеграм под декстоп просто летает и совершенно не тормозит.
                                            • 0
                                              А он разве на Electron?

                                              На Github есть его сорцы, там на C++ (Ну или Objective-C на Mac).
                                              • 0

                                                Я где-то читал, что он на патченом Qt5 без QML. Хотя первое время сам думал, что на Electron, уж модно нынче на нём такие вещи клепать)

                                              • 0
                                                Удивительно, но запускается он, будучи написанным на Qt, медленнее Chromium.

                                                Каждый день вот замечаю, почти одновременно их запуская (Telegram Desktop раньше, но всё равно его окно вижу позже, и речь о секундах).
                                                • 0
                                                  Хм, странно. Может это только системный телеграмм тормозной? Или что-то не так с системой.
                                                  Я пользуюсь портативной (standalone) версий, так даже при запуске с обычного диска или USB флешки (не SSD), даже на WinXP и относительно старых процессорах уровня Core 2 или Phenom запускается в пределах 1-2 секунд

                                                  Правда контактов и истории сообщений в нем мало, т.к. редко им пользуюсь.
                                                  • 0
                                                    Или что-то не так с системой.

                                                    Хороший SSD под рут, хорший HDD под /home, Intel i5 и i7.

                                                    Я пользуюсь портативной (standalone) версий, так даже при запуске с обычного диска или USB флешки (не SSD), даже на WinXP и относительно старых процессорах уровня Core 2 или Phenom запускается в пределах 1-2 секунд

                                                    Примерно такие ощущения: Chromium — 1–2 секунды до появления окна, Telegram Desktop — 3–4 секунды. Telegram Desktop запускается первым, повторюсь, но окно появляется позже.

                                                    Может и в истории дело, не знаю точно, но мне кажется вряд ли.
                                                    • 0
                                                      Я имел ввиду не железо (по железу даже на Core 2 + 2 ГБ памяти очень шустро работает, так что любого кроме совсем антикварного должно хватать), а ОСь и системное ПО. Но наверно все-таки дело истории.

                                                      Если есть винда как 2я система можно сравнить, я вот этой версией пользуюсь (установки не требует, просто запускается из любой папки): https://telegram.org/dl/desktop/win_portable
                                                      • 0
                                                        Если есть винда как 2я система можно сравнить

                                                        Есть, сравнил: на Arch Linux и Windows 10 одинаковый тайминг «холодного» (первый после старта системы) запуска, указанный выше. «Горячий» (повторный после полного выхода) запуск происходит почти мгновенно.

                                                        Portable не горю желанием тестировать :(
                                            • –1
                                              Боже мой 13%.) Когда в Windows запускаешь любую прогу от apple(iTunes, QuickTime), то о таком можно только мечтать. А тут ещё темболее такая ядерная смесь MacOS, JS, CSS.
                                              • +1
                                                и какое отношение mac os имеет ко всему этому?
                                                • +1
                                                  Человек думает, что в макоси itunes тоже тормозит.
                                                  • +1
                                                    И он там, не поверите, тормозит. То есть — медленно работает. Потому что любые действия в нём, кроме плеера, завязаны либо на работу с подключённым девайсом либо работают через встроенный веб-вью (ха-ха, почти электрон), т.к. весь магазин и вся Apple Music на вебе.
                                                    • 0
                                                      Но в винде-то тормозит даже плеер.
                                                      • 0
                                                        Что не делает чести программистам Apple.
                                                        • 0
                                                          Да я разве спорю.
                                                      • +1
                                                        Данные то нужно получить с телефона, а задержку никто не отменял.
                                                • 0
                                                  Проблема не в электроне как таковом, а в архитектуре самого редактора. Я не понимаю какой смысл реализовывать поле реактора через html теги — не для этого они предназначены. В данном случае идет постоянное изменение DOM.
                                                  Что мешало Microsoft использовать canvas — непонятно.
                                                  • +1
                                                    Затем, чтобы с помощью css стилизовать его содержимое. Холст — не серебрянная пуля. Да и если собираетесь использовать холст, то и злектрон вам ни к чему.
                                                    • 0
                                                      Проблема как раз-таки в DOM, в его топорной реализации.
                                                    • –12
                                                      Индусский код такой индусский! С тех пор как Microsoft возглавляет Сатья Наделла — корпорация регрессирует убыстряющимися темпами. И если Билли не успеет вовремя распродать свои акции, то они из богатейшего человека рискует превратиться в нищего.
                                                      • 0
                                                        Всё идет по старому.
                                                        • +2
                                                          В данном случае индусский код написали в гугле. И далеко не только микрософт напоролись на эту осовенность.
                                                          • +4

                                                            Вопрос еще в адекватности людей, пишущих десктопные приложения на JavaScript. Может ещё навигационное ПО для самолетов на нем начнут писать…

                                                            • 0
                                                              Было бы апи для управления самолётом — я бы с удовольствием написал ;-)
                                                              • 0
                                                                Ага… Вам на посадку заходить а тут object null does not have property foo.
                                                                • 0
                                                                  И это замечательно. Из-за сбоя синхронизации времени, отказала подсистема отображения времени, но остальные подсистемы продолжают работать. Устранение причины сбоя тут же восстанавливает работу сбоивших подсистем. Всяко лучше сегфолта при доступе по нулевому указателю.
                                                          • 0
                                                            «Чукча не читатель, чукча писатель»? Root cause проблемы — баг в Google Chrome, а не в Microsoft VS Code.

                                                            Что касается того, что сейчас происходит с Microsoft — я очень надеюсь, что они будут продолжать движение в ту же сторону. Тот Microsoft, что был при Баллмере, и тот, что есть сейчас — это две большие разницы, и тот, что сейчас, мне нравится куда больше. И Билли, думаю, тоже вполне щастлив тому, что при Наделле акции MSFT (которые при Баллмере в лучшем случае колебались на одном уровне) растут в цене, как на дрожжах.
                                                            • +1

                                                              Ну все, значит естетвенный отбор в IT поощряет мигающий курсор, отжирающий 13% ресурсов процессора и редактор кода, занимающий 8 Гб… Nothing to do here

                                                              • 0
                                                                Называть Visual Studio редактором кода — это как назвать Windows «браузером для веб». Это, мягко говоря, передергивание правды.
                                                                Про то, что оно весит дофига, спору нет — это потому, что и ставится дофига. Что было частично исправлено в VS 2017 (компоненты стали более гранулярными, и можно более детально выбрать, что ставить и что нет); моя установка весит меньше 4 Гб.
                                                                • +1
                                                                  моя установка весит меньше 4 Гб.

                                                                  Всё это понятно, но… она умеет делать принципиально что-то более сложное, чем, например, Visual Studio 6, которая весила раз в двадцать меньше? Причём я не имею в виду библиотеки, я только про саму IDE.
                                                                  • 0
                                                                    Из того, что я использовал — Intellisense, дебаггер нативного кода стали несравнимо лучше; добавились поддержка и отладка DirectX и GPGPU, .NET, ASP.NET/HTML/CSS/JS (и тд. — веб), мобильная разработка для Winphone и Android, включая эмуляторы и отладку, средства баз данных, толпы энтерпрайз-фич, которыми я не пользовался и тд.
                                                                    • +2
                                                                      Из того, что я использовал — Intellisense, дебаггер нативного кода стали несравнимо лучше

                                                                      Да, но оно же, никак не тянет на многократную разницу в размере и прожорливости ресурсов. Я ещё в Delphi 6 полтора десятилетия назад успешно отлаживал веб-приложения. Она слегка притормаживала на Celeron 700 с 128Мб ОЗУ. Студия там вообще летала. А сейчас у меня 16 Гб, 8 ядер, скоростной NVMe SSD, и она, зараза такая, на всём этом лагает.
                                                                      • 0
                                                                        Корень проблем лежит в кроссплатформенности. Платформы плодятся как грибы после дождя, производители не желают слышать ни о каких стандартах и ни о какой совместимости, фрагментированность устройств только растёт.
                                                                        У разработчиков просто нет выхода, кроме как вводить по 6 слоёв абстракций, если они хотят, чтобы единожды написанное приложение работало на максимально возможном количестве устройств.
                                                                        А эти абстракции, естественно, обходятся весьма недёшево.
                                                                        Была бы всего одна десктопная платформа и одна мобильная, со строго стандартизированным набором устройств и двумя-тремя разрешениями экрана, так городить абстракции и не потребовалось бы.
                                                                        • +1

                                                                          Visual Studio — исключительно виндовая программа.

                                                                          • –2
                                                                            https://developer.xamarin.com/visual-studio-mac/
                                                                          • +2
                                                                            Корень проблем лежит в кроссплатформенности.

                                                                            Мне кажется, корень проблем лежит в раздутых библиотеках. Когда один и тот же код дублируется, для выполнения простейших задач тянутся многомегабайтные либы, которые под руку подвернулись, и т.д. Просто потому, что фокус сместился с «писать так, чтобы был баланс между скоростью разработки и качеством софта» в сторону «писать как можно быстрее и дешевле». Кроссплатформенный код изобрели не вчера, та же Qt вопросы абстрагирования от Win32 и posix/Xwindow успешно закрывала и без малого 20 лет назад, и при этом приложения не были такими огромными.
                                                                            • 0
                                                                              Щито? В своё время QT приложения были «о майн факинг год!», да оно же жрёт 50 Мб в памяти!!!
                                                                    • 0

                                                                      Ну хорошо, пусть будет гордо и красиво "среда разработки", суть не особенно меняется: например среда разработки Eclipse весит в 20 раз, IDEA — тоже самое.

                                                                  • +1
                                                                    В выборе технологии у них баг был. Но, судя по Win10, этот баг без смены курса развития / всего топ-менеджмента MS — не починить.

                                                                    Правда, конечно, странно, что они стали использовать гугл хромиум вместо своего .NET к примеру. Это какой-то странный MS.
                                                                    • +1

                                                                      Видимо .NET не очень кросс-платформенный

                                                                • +7
                                                                  Что за ушлепки придумали интерфейс в десктопной системе на базе веб-технологий делать? Я конечно понимаю, что можно гораздо проще делать красиво и переносимо, но мне нужна функциональность. Меня на работе уже какахами закидали из-за 2013-2016 MS Office, который виснет из-за каждого чиха на i5.
                                                                  • 0

                                                                    Хотя, казалось бы, с ресурсами MS можно и человеческое native приложение сделать.

                                                                    • +4
                                                                      Есть такое приложение. Visual Studio называется.
                                                                      • 0
                                                                        Оно уже давно не человеческое
                                                                        • +1

                                                                          Ага, помню: я ещё сильно удивлялся, почему оно 8 Гб диска занимает против 300 Мб у Eclipse с плагинами, когда недавно его сносил.

                                                                      • –1

                                                                        Ужас в том, что кроссплатформенный софт на html рисуется шустрее, чем на java, что вообще кажется странной дикостью. Но вот если сравнить скорость отрисовки текста в vs code и qt creator, то последний рвет как тузик грелку.
                                                                        Жаль только, что там плагины подвозить на лету нет возможности, да и нет поддержки кучи языков.
                                                                        Хотя вот, справедливости ради, пробовал всего из себя нативного Gnome Builder, а он, оказывается, тормознее, чем VS Code, так, что все тормоза от плохих алгоритмов и архитектуры, а не от используемого языка.

                                                                        • 0

                                                                          Серьезно? А есть какие-то тесты, чтобы сравнить? А то по личному опыту Atom гораздо медленнее работает, чем тот же Eclipse.

                                                                          • +1

                                                                            vs code заметно шустрее атома

                                                                          • +1
                                                                            Кстати да, недавно смотрел qt creator — был приятно удивлен.
                                                                            Скорость реакции — мгновенная. Даже не думал, что так бывает.
                                                                        • +8
                                                                          Я конечно все понимаю, cross-platform, web-stack. Куча веб программистов которых можно запрячь за дешево. Работает и сойдет что не очень быстро.
                                                                          Но люди, человеки, остановитесь. Аппликации которые тянут за собой целый веб стэк, даже если они из себя представляют две кнопки. Тормоза UI, потому как вместо использования встроенных библиотек операционной системы, все виртуализируется по пять раз. Ладно еще память, ее не жалко, но процессоры то уже давно не резиновые, с учетом что на оптимизацию давно все забили.
                                                                          • –6
                                                                            Зря вы, тут за это минусуют.
                                                                            • 0
                                                                              эмм, я конечно не погромист. но писать по, думаю надо все же аккуратнее)
                                                                          • +1
                                                                            Ладно еще память, ее не жалко

                                                                            ну не знаю, slack с парой команд занимает ок. 1Гб. Мне — жалко.
                                                                          • +1
                                                                            Вы еще не программируете визуальщину на дельфи?
                                                                            Тогда мы идем к вам!
                                                                            Ни единого тормоза, лага, провисания fps и т.д… минимум памяти и процессора, все летает.
                                                                            И пусть будет 2005 год вечно, ничего лучше все равно не придумают.
                                                                            А теперь можно минусить до 1000, но это ничего не изменит же в убогом недомозге современных недопрограммистов :)
                                                                            • +5
                                                                              И все эти екзешники, скомпилированные в далёком начале 2000-х годов, весящие от 250 кб и не имеющие никаких внешних зависимостей, до сих пор отлично запускаются и работают хоть на Вин 98, хоть на десятке. Говорите, проблемы с масштабируемостью под высокую плотность пикселей? Да Win 8 без бубна из коробки не способна отрендерить чёткий незамыленный шрифт. Если всё изначально сломано под капотом самой ОС, незачем винить софт пятнадцатилетней давности.
                                                                              • 0
                                                                                Во-во ещё при КАЖДОМ выпуске пишут, что «около 75% кода новой ОС написано с нуля». Ладно, применительно к XP в это ещё можно поверить, но насчет 7, 8, 10 — категорически нет.
                                                                              • +3
                                                                                Слезу пустил'((
                                                                                • +1
                                                                                  Вам там в 2005-м хорошо, у вас по сути всего одна популярная ОС и всего одна платформа.
                                                                                  А теперь попробуйте запустить Delphi-приложение под Linux и MaxOS. Тут, внезапно, Lazarus соберёт бинарник куда как большего размера, чем дельфийские 250 Кб, да и работать оно будет не так шустро, и памяти выжрет побольше.
                                                                                  А что, если приложение нужно запускать ещё и на ARM-процессорах? А если на мобильных устройствах/планшетах?
                                                                                  Чем выше кроссплатформенность, тем больше весит приложение и тем менее эффективно оно использует ресурсы. QtCreator+QML — и вот оно уже тормозит вполне прилично. Добавим PyQt, и тормозов ещё больше. А переход к веб-приложениям просто ещё один шаг на этом пути.
                                                                                  Проблему можно решить исключительно дефрагментацией аппаратной части, но это из области фантастики, поэтому можно смело считать, что на данном этапе развития IT проблема неразрешима.
                                                                                  • 0
                                                                                    Чем выше кроссплатформенность, тем больше весит приложение

                                                                                    Написать под каждую платформу своё приложение религия не позволяет.
                                                                                    • +2
                                                                                      Как минмиум, мобильные приложения должны быть точно отдельными, а не пытаться использовать один дизайн для всех платформ.

                                                                                      И тут не «чем больше кроссплатформенность», просто не надо использовать интерпретируемые языки там, где нужна производительность.
                                                                                      • 0
                                                                                        Они не совсем интерпретируемые, там ведь JIT, и он работает вполне неплохо.
                                                                                        Проблемы тут другие. Во-первых, в большинстве современных языков напрочь отсутствует такая вещь, как линкер. Вы не можете, как во времена C++, выбрать из библиотеки только используемый код. Если из всей библиотеки вам нужна всего одна функция, библиотека всё равно будет включена в проект целиком. Современные проекты состоят по большей части из мёртвого кода, который никогда не выполняется — такова плата за отсутствие статической типизации и возможность динамической компоновки произвольных объектов, структура которых точно неизвестна на момент сборки проекта.
                                                                                        Во-вторых, автоматическое управление памятью, т.е. сборщик мусора. Существует даже расхожая шутка, мол Java догонит по быстродействию C++, как только изобретут компьютер с бесконечным количеством памяти.
                                                                                        Языки со сборкой мусора всегда будут жрать существенно больше памяти и притормаживать в моменты, когда отрабатывает этот самый сборщик.
                                                                                        • 0
                                                                                          Ну вот про «существенно больше» вы сильно так загнули. При статической типизации памяти будет уходить [почти] столько же. Конечно, «положить» можно любой сборщик мусора, если задаться такой целью, но это если задаться.
                                                                                      • 0
                                                                                        QtCreator+QML — и вот оно уже тормозит вполне прилично.

                                                                                        Qt Creator — это среда разработки, каким образом она влияет на тормоза конечного продукта? А QML достаточно бодро работает, если уметь его готовить.


                                                                                        Добавим PyQt, и тормозов ещё больше.

                                                                                        Пользуюсь приложением на PyQt — тормозов не заметил.

                                                                                    • –4
                                                                                      Вот вам и ынтырпрайз. Русский ваня быстренько бы заменил step-start на steps(10) и брат был бы жив. А эти консилиум собирают.
                                                                                      • +1
                                                                                        К сожалению, Хром плевать хотел на ваш steps и фигачит любую анимацию с 60 fps.
                                                                                      • +1
                                                                                        Я еще могу вспомнить что в старом добром текстовом режиме 80*25 символов мигающий курсор рендерился аппаратно в видеокарте, что потребляло 0% процессорного времени. Вот так вот… вполне кроссплатформенно кстати:)
                                                                                        А теперь веб на вебе, я конечно и сам понимаю что веб это настоящее и будущее (и сам активно изучаю веб технологии) но создавать на веб стеке среды разработки это ИМХО перебор. Все должно применяться по своему назначению и никак иначе. Веб — для веба, нативные приложения — для тяжелых задач в оффлайне.
                                                                                        • 0
                                                                                          Хм, я один пропустил момент когда Visual Studio стал запускать на Маке?
                                                                                          • +3
                                                                                            Visual Studio Code и Visual Studio — совершенно разные программы.
                                                                                            Первое — под капотом Хромиум и javascript. Потому и запускается на трёх OS, и плагины кроссплатформенные.
                                                                                            • 0

                                                                                              Ну вообще правда пропустили.
                                                                                              https://www.visualstudio.com/vs/visual-studio-mac/

                                                                                            • +2

                                                                                              А вот был бы там нормальный сценический граф, он бы сразу понял, что достаточно просто перестроить только один жалкий узел.

                                                                                              • +2
                                                                                                Напомнило — почему из Windows убрали мигающее двоеточие и секунды в таскбаре —
                                                                                                https://blogs.msdn.microsoft.com/oldnewthing/20031010-00/?p=42203
                                                                                                • 0
                                                                                                  Выглядит ужасно, но я так понимаю, что это не вина MS, Electron основан на детище Google, который и обеспечивает отрисовку.

                                                                                                  С другой стороны, увлечение Electron'ом понятно: как ещё можно сделать кросплатформенное приложение с поддержкой тем оформления без необходимости рисовать UI для каждой ОС отдельно с помощью native-технологий. А вот серьезно — может кто-нибудь что-то подобное подсказать?
                                                                                                  • +5
                                                                                                    может кто-нибудь что-то подобное подсказать?
                                                                                                    GTK? QT?: ехидно: tcl/tk?
                                                                                                    • 0
                                                                                                      Avalonia?
                                                                                                      • +1
                                                                                                        wxWidgets, FLTK, FOX toolkit
                                                                                                        • 0
                                                                                                          HTMLayout/Sciter? Который тоже HTML/CSS/TiScript, но сильно тоньше.
                                                                                                          EDIT: не туда, отвечал на https://geektimes.ru/post/287342/#comment_9967202
                                                                                                      • –1

                                                                                                        Всегда мечтал наблюдать мигающий курсор в 60фпс. Это же такая плавная картинка.
                                                                                                        Кстати, а почему именно 60? Всинк? А если у меня монитор 75гц? А если 120? Сожрет четверть производительности цп на отрисовку курсора?

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