Эпическая дискуссия про: VS Code Uses 13% CPU When Idle Due to Blinking Cursor
От: c-smile Канада http://terrainformatica.com
Дата: 24.03.17 17:33
Оценка: 11 (7) :))) :))) :)))
VS Code Uses 13% CPU When Idle Due to Blinking Cursor Rendering

Проблема: если оставить на экране VS Code с редактором в фокусе c моргающей кареткой и ничего не делать то редактор съедает 13% CPU.

https://www.reddit.com/r/programming/comments/612v99/vs_code_uses_13_cpu_when_idle_due_to_blinking/
https://news.ycombinator.com/item?id=13940014

Assuming 1 million users of VS Code This blinking cursor will waste $3 million per year in electricity costs, and output 32,000 tons of c02 per year.


2150: "Grandpa, why did the ocean's dry up?"
"well sonny, long ago, Microsoft didn't optimize their code for a code editor's cursor and pushed earth's climate over the edge"


Суть:

Это все про Microsoft Visual Code который как известно есть Electron application — Chromium based.

Курсор они моргают этим вот CSS кодом:

@keyframes monaco-cursor-blink {
    50% {
        opacity: 0;
    }
    100% {
        opacity: 1;
    }
}

.cursor-blink {
    animation: monaco-cursor-blink 1s step-start 0s infinite;
}


Там две проблемы:

1. Типа bug в самом chromium / webkit: эта анимация исполняется с частотой animation frame rate — each 16ms — 60 FPS.
2. Т.к. Chromium (WebKit со Skia backend) это mostly CPU rasterization то это в общем-то простое действо (fill 1px rectangle) потребляет CPU ресурсы как не в себя. На каждый frame rate перерисовывается всё окно.

Ну и сами авторы VS Code тоже в общем-то виноваты, вместо тривиального односекудного setTimer(blink, 1000) запузырить туда animation.
Re: Эпическая дискуссия про: VS Code Uses 13% CPU When Idle
От: Sinix  
Дата: 24.03.17 18:11
Оценка:
Здравствуйте, c-smile, Вы писали:


CS>Курсор они моргают этим вот CSS кодом:


"Я видел нечто, во что вы, люди, просто не поверите."(с) и далее по тексту.

UPD: вот эти два предложения, по-моему, раскрывают тему полностью:
1.

Suggestions here to render the CSS animation using the GPU instead of the CPU:

.cursor-blink {
    will-change: opacity;
}


2.

why don't we wrap the carat in <blink></blink> instead?

Отредактировано 24.03.2017 18:18 Sinix . Предыдущая версия .
Re: Эпическая дискуссия про: VS Code Uses 13% CPU When Idle Due to Blinking Curs
От: Mystic Artifact  
Дата: 24.03.17 18:13
Оценка: 2 (2) +1
Здравствуйте, c-smile, Вы писали:

VSCode 1.10.2 — у меня при любом раскладе выжирает ~<1% (0.2-0.8% в сумме для всех процессов)... правда цифра из task manager бесполезная — зависит от количества ядер. Ну можно умножить на 8.
А вот взрослая студия в "покое" — у меня стабильно жрёт >1%. Сейчас 1.3. А бывает 5. При этом она наглухо свёрнута.
Но этим страдают много кто.

CS>1. Типа bug в самом chromium / webkit: эта анимация исполняется с частотой animation frame rate — each 16ms — 60 FPS.

Баги-багами, но это ещё зависит от editor.cursorBlinking который например может быть smooth и который точно будет требовать точную анимацию.

CS>2. Т.к. Chromium (WebKit со Skia backend) это mostly CPU rasterization то это в общем-то простое действо (fill 1px rectangle) потребляет CPU ресурсы как не в себя. На каждый frame rate перерисовывается всё окно.

Если такое происходит — это точно баг. У меня — перерисовывается только область курсора. Легко проверить через Help -> Toggle Developer Tools. Три точки -> More tools -> Rendering settings:
Друзья:
— Paint Flashing
— Layer Borders
— FPS Meter
FPS meter у меня показывает ~2fps. А вот при "editor.cursorBlinking": "smooth" — уже ~27fps.
Насчет того что перерисовывает "всё" — то это уже от кривизны лайаута и зависит. В худшем случае попадаем на перерисовку слоя (тот который квадрат 256х256 (или 512)), остальное должно отсекаться, если не затрагивается.
Я тут где-то писал — вот в google sheets — кликание по клеткам действительно приводит к перерисовке всего листа из-за того как сделана обводка вокруг ячейки (сейчас лень перепроверять — могли и пофиксить).
Ну а баги... бывают. По хорошему нужно тесты запиливать на такое, потому что — неправильная верстка — привет, мир. Обновили движок — а в нём баг — опять привет мир. Но видать до этого ещё не добрались.

CS>Ну и сами авторы VS Code тоже в общем-то виноваты, вместо тривиального односекудного setTimer(blink, 1000) запузырить туда animation.

Декларативненько ж...
Re[2]: Эпическая дискуссия про: VS Code Uses 13% CPU When Id
От: c-smile Канада http://terrainformatica.com
Дата: 24.03.17 19:21
Оценка: 2 (1)
Здравствуйте, Mystic Artifact, Вы писали:

MA>Если такое происходит — это точно баг. У меня — перерисовывается только область курсора.


Говорят что это в основном на MacOS проявляется.

В любом случае это специфика именно Chrome и его самописного rasterization engine (Skia).

По идее все rendered objects должны сидеть в GPU. Меняется только отсутствие/присутствие того caret bar rectangle.
Т.е. даже в случае 60 FPS update ничего радикального не должно происходить.

Вот в Sciter примерно такое же функциональности окно (editor c syntax highlighting):

Direct2D backend:



А это вот один из rendering процессов VS Code (всего VS Code запускает 8 процессов на это бедное окно):



А это вот все тот же Sciter но со Skia backend — тем же что использует Chromium:


Это все на Win10 где Microsoft сильно отрихтовала OpenGL поддержку (исп. Skia в Sciter). На W7 разница D2D/OpenGL должна быть более значительна.
Отредактировано 24.03.2017 19:23 c-smile . Предыдущая версия .
Re[3]: Эпическая дискуссия про: VS Code Uses 13% CPU When Idle Due to Blinking C
От: Mystic Artifact  
Дата: 24.03.17 19:23
Оценка:
Здравствуйте, c-smile, Вы писали:

У тебя последняя картинка неправильная (указывает на vs-code).
Re[4]: Эпическая дискуссия про: VS Code Uses 13% CPU When Idle Due to Blinking C
От: c-smile Канада http://terrainformatica.com
Дата: 24.03.17 19:25
Оценка:
Здравствуйте, Mystic Artifact, Вы писали:

MA>У тебя последняя картинка неправильная (указывает на vs-code).


Починил
Re[3]: Эпическая дискуссия про: VS Code Uses 13% CPU When Id
От: Mystic Artifact  
Дата: 24.03.17 19:33
Оценка:
Здравствуйте, c-smile, Вы писали:

По твоим картинкам в основном понятно только то, что VSCode делаёт ещё что-то (что и не удивительно).
Отличия понятно, что есть. Ты то сам как курсор рисуешь, и реально к каким перерисовкам приводит его отрисовка?
Re: Эпическая дискуссия про: VS Code Uses 13% CPU When Idle Due to Blinking Curs
От: alex_public  
Дата: 24.03.17 20:00
Оценка: +2
Здравствуйте, c-smile, Вы писали:

Я так подозреваю, что 13% — это просто 1/8 процессора. ))) Т.е. по сути речь идёт о 100% загрузке одного ядра — возможно оно и больше могло бы сожрать, просто упёрлось в потолок. ))) Явно баг какой-то. )))
Re[3]: Эпическая дискуссия про: VS Code Uses 13% CPU When Id
От: antropolog  
Дата: 25.03.17 13:39
Оценка: +1 -1
Здравствуйте, c-smile, Вы писали:

CS>В любом случае это специфика именно Chrome и его самописного rasterization engine (Skia).

вы так написали "самописного" как будто этот енжин вчерашний школьник писал. Скиа не более "самописная" чем Direct2D, Cairo или Sciter К тому же у skia есть разные бекенды, как софтверные так и gpu-accelerated.

CS>По идее все rendered objects должны сидеть в GPU. Меняется только отсутствие/присутствие того caret bar rectangle.

Skia или хром этому не помеха. И вообще очевидно, что хром, затачиваемый в том числе на использование в мобилках, будет как минимум осведомлён о gpu. И уж что-что а оперировать слоями на уровне GPU он может ( чуть подробнее здесь: UI Elements at 60fps )
Re[4]: Эпическая дискуссия про: VS Code Uses 13% CPU When Id
От: c-smile Канада http://terrainformatica.com
Дата: 25.03.17 17:26
Оценка:
Здравствуйте, antropolog, Вы писали:

A>Здравствуйте, c-smile, Вы писали:


CS>>В любом случае это специфика именно Chrome и его самописного rasterization engine (Skia).

A>вы так написали "самописного" как будто этот енжин вчерашний школьник писал. Скиа не более "самописная" чем Direct2D, Cairo или Sciter К тому же у skia есть разные бекенды, как софтверные так и gpu-accelerated.

"самописный" не означает что его школьник написал. Скорее отражает тот факт что Skia написана как статическая библиотека которая максимально дистанциируется от системных средств.
И эта дистанция имеет цену: там где Direct2D использует JIT для имплементации эффективного rasterization (когда что-то нужно делать на CPU side) Skia надеется на оптимизирующий С/С++ compiler. Что не всегда the case.

Статичность же библиотеки означает то что у неё нет стабильного API — т.е. это сугубо встраиваемая вещь.

Например Android UI использует Skia под капотом, но эта Skia не доступна native приложениям поэтому тот же Chrome на Android использует свою копию Skia.
И хорошо если они обе используют OpenGL в качестве final composition layer а не банальный pixmap в heap. Но если screen может работать с OpenGL напрямую то приложения уже должны работать через OpenGL frame buffer (FBO) что является больным местом OpenGL исторически.

Для эффективного OpenGL hardware acceleration приложение должно быть fullscreen. Что в UI далеко не всегда возможно да и вообще имеет смысл.

CS>>По идее все rendered objects должны сидеть в GPU. Меняется только отсутствие/присутствие того caret bar rectangle.

A>Skia или хром этому не помеха. И вообще очевидно, что хром, затачиваемый в том числе на использование в мобилках, будет как минимум осведомлён о gpu. И уж что-что а оперировать слоями на уровне GPU он может ( чуть подробнее здесь: UI Elements at 60fps )

Не понял как это видео соотносится с обсуждаемой темой кроме обсуждения will-change которое на самом деле вообще никому не нужно. Когда исполняется transition всегда есть два property set — start и target. Построить дельту свойств которые отличаются — тривиально. Ну да это все далеко от обсуждаемой темы про hardware acceleration.
Re[2]: Эпическая дискуссия про: VS Code Uses 13% CPU When Idle Due to Blinking C
От: c-smile Канада http://terrainformatica.com
Дата: 25.03.17 17:49
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Здравствуйте, c-smile, Вы писали:


_>Я так подозреваю, что 13% — это просто 1/8 процессора. ))) Т.е. по сути речь идёт о 100% загрузке одного ядра — возможно оно и больше могло бы сожрать, просто упёрлось в потолок. ))) Явно баг какой-то. )))


Не факт. Нужно знать платформу на которой замеры производились.

Дело в том что MacOS измеряет загрузку одного core, а Windows — всего процессора.

Т.е. в Windows цифры загрузки больше 100% невозможны, а в MacOS ты можешь увидеть 200% если процесс загружает два ядра полностью.

Т.е. MacOS/13% это Windows/3.25% что в общем-то близко к аналогичным измерениям MS Code на Windows.
Re[3]: Эпическая дискуссия про: VS Code Uses 13% CPU When Idle Due to Blinking C
От: alex_public  
Дата: 25.03.17 19:46
Оценка:
Здравствуйте, c-smile, Вы писали:

_>>Я так подозреваю, что 13% — это просто 1/8 процессора. ))) Т.е. по сути речь идёт о 100% загрузке одного ядра — возможно оно и больше могло бы сожрать, просто упёрлось в потолок. ))) Явно баг какой-то. )))

CS>Не факт. Нужно знать платформу на которой замеры производились.
CS>Дело в том что MacOS измеряет загрузку одного core, а Windows — всего процессора.
CS>Т.е. в Windows цифры загрузки больше 100% невозможны, а в MacOS ты можешь увидеть 200% если процесс загружает два ядра полностью.
CS>Т.е. MacOS/13% это Windows/3.25% что в общем-то близко к аналогичным измерениям MS Code на Windows.

Так процент от только физических ядер или всё же логических (как на винде)? ) Ну и если речь о 13% от одного логического ядра, то это уже близко к норме для современного сложного ПО (например браузеры обычно столько же едят). )))
Re[5]: Эпическая дискуссия про: VS Code Uses 13% CPU When Id
От: Mystic Artifact  
Дата: 25.03.17 20:33
Оценка:
Здравствуйте, c-smile, Вы писали:

CS>Статичность же библиотеки означает то что у неё нет стабильного API — т.е. это сугубо встраиваемая вещь.

Я не стал обращать внимания, но меня тоже "самописность" возмутила. И вроде бы ж как Skia — как раз родом из андроида, а не хрома. Но это всё ерунда.
Я тут хотел уточнить — что у либы проблемы не со статичностью как таковой, а с тем что она намертво привязана к C++. Не так сильно как V8, но всё же есть.
Отсюда и вся статичность.
Интересный вопрос на самом деле — ведь на DX выходит не хуже у некоторых, а там... никакой магии.
Re: Эпическая дискуссия про: VS Code Uses 13% CPU When Idle Due to Blinking Curs
От: 463C21E2  
Дата: 27.03.17 21:17
Оценка:
Здравствуйте, c-smile, Вы писали:

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


CS>Там две проблемы:


CS>1. Типа bug в самом chromium / webkit: эта анимация исполняется с частотой animation frame rate — each 16ms — 60 FPS.

CS>2. Т.к. Chromium (WebKit со Skia backend) это mostly CPU rasterization то это в общем-то простое действо (fill 1px rectangle) потребляет CPU ресурсы как не в себя. На каждый frame rate перерисовывается всё окно.

CS>Ну и сами авторы VS Code тоже в общем-то виноваты, вместо тривиального односекудного setTimer(blink, 1000) запузырить туда animation.


Сначала я посмеялся. А потом, подумавши, решил, что не над чем тут смеяться. Как уже написали выше, их решение декларативное, а не императивное (на языке современных веб-девелоперов: 'pure CSS'). Поэтому, пусть лучше в Хромиуме чинят перф. (В Хроме все нормально).

Единственное, что... Согласно этому списку, им было доступно visibility. В Хромиуме лень проверять, а в Хроме это работает:

@keyframes monaco-cursor-blink
        {
            50%
            {
                /*opacity: 0;*/
                visibility: hidden;
            }

            100%
            {
                /*opacity: 1;*/
                visibility: visible;
            }
        }


Я даже сначала не въехал в прикол, потому, что из-за opacity не увидел step-start (как бы, предполагается linear). Думал, дезигнеры eye-candy добавили, которую таймером никак не сделать. Но я не удивлюсь, если изначально они и планировали linear, а потом по каким-то причинам отказались. Если мое предположение верно, такой подход еще и универсальнее, т.к. в будущем можно добавить настройку "Мигать курсором плавно". Если и это кому-то покажется смешным, я напомню, что для code editor такие нюансы — не последнее дело, я одно время в студии PHP редактировал просто потому, что как текстовой редактор она мне нравилась, хотя PHP никоим боком не поддерживала. А если мое предположение неверно, то, конечно, надо было использовать visibility.

Пользуясь случаем, спрошу у человека, который принимает участие в стандартизации: а зачем вообще (в W3C?) ввели понятие 'animatable property'? Вот тут написано так:

As it doesn't make sense to animate some properties, the list of animatable properties is limited to a finite set.


Тем не менее, легко представить задачу, когда в невидимой фазе элемент не должен занимать места, а display: none; туда не засунуть
Re[2]: Эпическая дискуссия про: VS Code Uses 13% CPU When Idle Due to Blinking C
От: Mystic Artifact  
Дата: 27.03.17 21:27
Оценка:
Здравствуйте, 463C21E2, Вы писали:

CE>Я даже сначала не въехал в прикол, потому, что из-за opacity не увидел step-start (как бы, предполагается linear). Думал, дезигнеры eye-candy добавили, которую таймером никак не сделать. Но я не удивлюсь, если изначально они и планировали linear, а потом по каким-то причинам отказались. Если мое предположение верно, такой подход еще и универсальнее, т.к. в будущем можно добавить настройку "Мигать курсором плавно".

Это уже есть: настройка editor.cursorBlinking (smooth например).
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.