усы2

Стой под стрелой

Поступки и мысли, о которых могу вспомнить не краснея

Previous Entry Поделиться Next Entry
Помедленнее, я записываю
усы2
tonsky

Ну что, я нашел еще одну метрику, чтобы меряться и унижать других.

Вот это — ultimate статья про latency редакторов. Подробно разбираются все задержки и весь overhead между нажатием клавиши пальцем и появлением символа на экране. Как вы догадываетесь, IDE и редакторы выступают сильно по-разному.

Мои измерения (MacBook Pro 2,3 GHz i7, Mid 2012):

Меряются именно задержки в редакторе, нажатия кнопок генерятся программно. Если я правильно понял, то v-sync, double buffering и compositing в эту цифру включены, а вот буфер/лаг в мониторе и задержки внутри клавиатуры/USB надо еще добавить. И это все на пустых файлах без синтаксиса, т.е. в реальности там еще доложится.

Да, теперь факт что «IDEA тормозит» научно доказан! Zero-latency typing улучшает ситуацию, но не так кардинально, как их намеряли в статье (может, из-за ОС?)

Мой рабочий редактор Light Table выступил одним из худших. Плюс я еще пишу на 30Hz мониторе (+16 ms avg задержки) и wireless клавиатуре (хз). Ну и в OS X v-sync и double buffering особо не выключишь (впрочем, в Windows 8 наверняка тоже). Пока думаю, что делать.

Может ли человек это заметить? Ощущал ли я тормоза до того, как прочитал статью и сам себя убедил, что они есть? Определенно да. Например, я абсолютно интуитивно слез с iTerm на Terminal, потому что в нем печатать приятнее. Маленькая задержка создает в мозгу ощущение «эти буквы я буквально произвожу», а большая — как вести диалог, перекрикиваясь с человеком в другом конце пещеры (с моей стороны сигнал ушел, посмотрим что он там сделает). О задержке как таковой не думаешь, но общее ощущение, что тяжеловато.

Обратите внимание, что Vim в голом виде практически ничего не добавляет к оверхэду редактора. Но стоит добавить банальнейшие status bar или, еще хуже, powerline, как все катится к чертям:

Внезапно отлично выступил GNU Emacs для десктопа. В терминале уже помедленнее, а Aquamacs вообще недоразумение:

Ну и внезапно шутки про «программировать в блокноте» уже не такие уж и шутки. Посмотрите, как выступил Text Edit:

Тулза для измерения


  • 1
(Анонимно)
Переходить на Emacs + cider. Light Table понативнее, но сыроват и со своими проблемами.

Я скорее свой редактор напишу на C++, чем Емакс выучу

без темы (Анонимно) Развернуть
без темы (Анонимно) Развернуть
Голый Emacs хорошо себя показывает.

Голый Emacs в правильном терминале!

без темы (Анонимно) Развернуть
без темы (Анонимно) Развернуть
без темы (Анонимно) Развернуть
хм, ну vscode мне всегда казался несколько поотзывчивей atom-а

Чем больше редактор берёт на себя функционала, тем дольше думает. (Особенно, когда смотришь XML мегабайт на пять)

Но в том же Емаксе можно просто отключить подсветку или автодобавление, если не нравится скорость.

Тогда зачем он нужен? Функциональности нет, а пальцы болят. :)

Круто, спасибо! Цифры я такими и предполагал, просто теперь можно научно впечатать оппонента, который не верит, что емакс тормозит (не хуже идеи иногда).

Погляди, я добавил десктопный емакс в статью :)

без темы (Анонимно) Развернуть
Охуенно, может наконец благодаря таким тулзам, кто-то возьметься выдрачивать зеро латенси минималистичный редактор с макросами.

Сейчас в разработке xi-editor и 4coder. Не знаю как у них с макросами, правда, но хотелось бы чтобы на latency обращать внимание стали. Chrome вот ввел моду на быстрые браузеры, может и тут получится что-то

Посмотри на BeOS-ный CodeWarrior или Haiku-шный Paladin IDE на основе PEdit (может вдохновят на что-то). Это вариант не далекий от TextEdit. Там реально было удобнее чем в Visual Studio C++ 6.0.

Edited at 2016-05-05 11:50 (UTC)

VS как себя показывает? Субъективно печаль-печаль.

без темы (Анонимно) Развернуть
(Анонимно)
Пописываю сейчас свой редактор (как делают и сотни других людей вроде https://github.com/google/xi-editor), где отрисовка текста и ввод-вывод идет практически на самом доступном низком уровне, а остальное вторичное — от анализа текста и синтаксиса до каких-то интерактивов — бежит в других тредах асинхронно. 22ms avg, но хотя и ожидал меньшее число. В каком-то смысле тут постоянный trade-off: приходится решать что должно быть синхронно, а что можно принять с лагом (как пример: скобочки закрываться или табы автоматически выравниваться предыдущей строке). Какое-нибудь вычисление номера строки тоже синхронное. В каком-то смысле тут можно даже найти проблему синхронизации данных, хотя это и offline stand-alone десктоп приложение: пока в главном треде state уже уехал дальше его нужно смерджить с данными которые пришли из других тредов.

Надеюсь подобный подход к тестированию станет стандартом в индустрии и какой-нибудь next-gen редактор будет по крайней мере давать прозрачные методы посмотреть что там внутри утяжеляет процесс и какие есть пути его настроить. В VR задержки меньше, а тут какой-то текст.

Вот когда на midi-клавиатуре играют, то задержка 5мс между нажатием и звуком считается абсолютным максимумом с которого вообще можно играть, всё что выше ощущается немедленно и весьма неприятно.

Примерно с тем же прицелом разрабатывается xi-editor. Там в качестве ограничения стоит время отклика 16мс, больше низя.

Я кстати не до конца понимаю почему именно 16мс? Это же с потолка взятая цифра? Скажем, кадр через 3мс, и тут приходит onKeyDown.

и ещё один повод использовать емакс :)

а аквамакс - таки да, недоразумение и его никто кроме группки укушенных не использует.

шо, уже совсем такая скука?

Спасибо за экспериментальное подтверждение известного факта про быстроту Емакса.

не холивара ради, но в жизнь не поверю, что чистый емакс быстрее чистого вима.

Люди разное под быстрее понимают. Скорость запуска, скорость открытия файлов/переключения/поиска по файлам, индексации. Здесь речь только о typing latency. Ну и это конкретно на MacOS, где я тестировал MacVim. На Линуксе без double-buffering GVim очень хорошо себя показал, судя по статье.

И что, вы хотите сказать что кто то действительно может заметить разницу между 50 и 10 микросекундами?
Причем не просто заметить, а так что "кушать не может"?

Прграммирование это же не про набор простыней текста. Ну сколько в среднем программист набирает кода за день? Несколько сотен строчек максимум.

Я полностью поддерживаю вашу идею о сокращении времени цикла разработки (редактироваине - компиляция - выполнение). Это действительно важно. Но там же речь идет о секундах а не о микросекундах. Кого может интересовать задержка в 50 ms в редакторе?

Edited at 2016-05-06 09:25 (UTC)

Осознанно — нет, на уровне ощущений — да. И это влияет на удовольствие от работы. Включите монитор в 30Hz и посмотрите, как комфортно вам будет. А это всего 16 мс дополнительной задержки.

А смысл стремиться к околонулевой задержке? Все эти задержки - это же не блажь, а попытки IDE сделать программисту хорошо - автокомплит, подсветка, анализ кода "на ходу".

безусловно быстрее всего будет писать код в консоли с выводом в файл, только вот много кто помнит, по памяти, все методы и типы параметров всех используемых библиотек? ;)

Редактор emacs совсем не медленный


  • 1
?

Log in