noJS desktop
Jun. 30th, 2022 12:37 pmРазумеется, у меня категорически нет времени на это, но мне кажется, что весьма достойной стратегической целью будет избавляться от JS как участника tight loop interactions на десктопе.
Во-первых это, конечно, очередной шпынок в сторону vscodium. Но во-вторых (и это немного неожиданно для меня), это cinnamon. Который, в целом, не плох, хотя иногда медленный. Раньше я не обращал внимание на это, пока не залез в какой-то багрепорт по cinnamon и не обнаружил /usr/share/cinnamon/js/ui/runDialog.js
Эта штука (вместе с остальными js/ui) явно находится в tight loop, и это js. Зачем? А, может, не надо?
Таким образом, задуматься о смене DE теперь подталкивает не только wayland, но и, в целом, не желание видеть избыток интерпретируемых языков..
О, кстати, это уже более достойная история. Как насчёт плавного ухода от tight loop с участием интерпретируемых языков для инструментов? Внезапно, под угрозой оказывается terminator. Который слишком хорош, чтобы просто выкинуть. Но, может быть, alacritty окажется лучше, хотя совмещение alacritty с чем-то типа tmux'а начинает звучать как отдельное приключение...
Ещё одной альтернативой будет WM с человечным тайлингом. Чтобы не "всё или ничего", а чтобы для группы окон был разумный тайлинг, а кто не в группе, тот обычные окна...
Во-первых это, конечно, очередной шпынок в сторону vscodium. Но во-вторых (и это немного неожиданно для меня), это cinnamon. Который, в целом, не плох, хотя иногда медленный. Раньше я не обращал внимание на это, пока не залез в какой-то багрепорт по cinnamon и не обнаружил /usr/share/cinnamon/js/ui/runDialog.js
Эта штука (вместе с остальными js/ui) явно находится в tight loop, и это js. Зачем? А, может, не надо?
Таким образом, задуматься о смене DE теперь подталкивает не только wayland, но и, в целом, не желание видеть избыток интерпретируемых языков..
О, кстати, это уже более достойная история. Как насчёт плавного ухода от tight loop с участием интерпретируемых языков для инструментов? Внезапно, под угрозой оказывается terminator. Который слишком хорош, чтобы просто выкинуть. Но, может быть, alacritty окажется лучше, хотя совмещение alacritty с чем-то типа tmux'а начинает звучать как отдельное приключение...
Ещё одной альтернативой будет WM с человечным тайлингом. Чтобы не "всё или ничего", а чтобы для группы окон был разумный тайлинг, а кто не в группе, тот обычные окна...
no subject
Date: 2022-06-30 12:20 pm (UTC)tight loop, это цикл взаимодействия ПО/человек, котором время реакции ПО определяет уровень комфорта человека.
На современном железе seamless/instant experience - это ответ ПО на действия человека за время меньшее 4 мс. Верхняя граница "отлично" - 16 мс. Всё что ниже - компромисс.
На самом деле технология второстепенна, но если какие-то внутренние технические причины приводят к tail latency на ожидаемо быстрой операции в 200мс вместо 10, то эта технология просится на выход. Моё наблюдение, что JS обычно добавляет много latency, во-первых в трансляции события в вовнутрь JS, а во-вторых из-за шанса наткнуться на GC (что отличный кандидат на основную причину tail latency).
tail latency - это значение в старших персентилях. Например, 99.9% действий выполняются за < 10мс, а 0.01% натыкается на "gc" или какую-то congestion в event loop'е и отрабатывает за 200мс, и это - tail latency. Даже если average latency получается 20мс, с точки зрения качества взаимодействия (tight loop) цифра 200мс (или даже 2с в 0.01% случаев) более критическая метрика.
no subject
Date: 2022-06-30 06:39 pm (UTC)no subject
Date: 2022-07-01 08:43 am (UTC)Конечно, может. Но в JS это обычно куда более заметно, плюс огромный оверхед. (конечно, тут прибегают js-фаны, у которых js-код обгоняет всё, включая v8 по производительности).
no subject
Date: 2022-07-01 10:38 am (UTC)no subject
Date: 2022-07-02 08:50 am (UTC)cat /usr/share/cinnamon/js/ui/runDialog.js|wc -l 478
Примерно в 20 раз больше, чем 20 строчек.