Если из кода убрать sleep(), то он перестаёт так тормозить!

Подача уровня желтухи. Раньше нужды не было в таком режиме обновлять содержимое. Это ж терминал. Со временем такая потребность возникла - выровняли до частоты монитора.

Лично у меня потребность в более отзывчивом терминале возникла только при использовании cava. И это единственное. Возможно есть какой-то реальный софт, требующий такую реактивность, но лично я такой не встречал.

Эээ… Вот полугодовой давности бенчмарк:

I have a 655MB file with 1.5 million lines of lorem ipsum. I timed a cat in several terminal emulators. For this simple test, gnome-terminal beat xterm a little bit but wasn't anywhere close to the rest:

  foot             0m9.410s
  alacritty        0m16.881s
  konsole          0m36.737s
  gnome-terminal   1m1.096s
  xterm            1m16.919s

Разница типа в шесть раз, карл.

А можно какой-то реальный юзкейс где необходима такая скорость вывода? Данный бенч ничего общего с реальной жизнью не имеет.

А можно какой-то реальный юзкейс где необходима такая скорость вывода? Данный бенч ничего общего с реальной жизнью не имеет.

Вывод в терминал не имеет ничего общего с реальной жизнью? Ну как скажешь.

Я, как пользователь гнома и представитель интересов подавляющего большинства его пользователей, очень негодую что его разработчики не бросили все силы на оптимизацию терминала ведь я каждый день утром просматриваю содержимое всех файлов системы на случай если их за ночь подменили. Скорости вывода больше 200к строк в секунду хватило бы для меня, но к сожалению разработчики гнома как всегда не понимают что нужно его пользователям.

Прочитай внимательно о чем я написал. Два раза.

Прочитай внимательно о чем я написал. Два раза.

А не то что?

Это ж терминал. Со временем такая потребность возникла - выровняли до частоты монитора.

А почему все остальные терминалы такой срани не делали? Это не отсутствие фичи, это наоборот специально запиленный таймер со слипами и синхронизацией. И почему-то именно на 40Hz, что не совпадает и никогда не совпадало с частотой вообще чего-либо.

Лично у меня потребность в более отзывчивом терминале возникла только при использовании cava.

Процитирую великого saahriktu: «Не всем нужен не лагающий терминал!»

Alacritty, which is our baseline, did not change from F39 to F40, as expected.

Забавно что они с foot не замеряли, который в два раза быстрее. Им стыдно штоле?

The main change that caused this much improvement is likely this one by Christian that moves away from a 40 Hz VTE repaint timer to drawing every frame, synchronized with the monitor, as any self-respecting GTK widget should do.

Возможно поэтому GTK так тормозит. Потому что там тоже 40Hz.

А есть бенчмарки по которым видно что современный GTK тормозит? У меня просто gnome 46 на слабом железе работает гораздо плавнее чем kde 6, macos на m3 pro, оптимизированная винда 11 на 12700K+4090.

А есть бенчмарки по которым видно что современный GTK тормозит? У меня просто gnome 46 на слабом железе работает гораздо плавнее чем kde 6, macos на m3 pro, оптимизированная винда 11 на 12700K+4090.

Тут недавно было тред где кто-то жаловался что gtk тормозит как сучка во время ресайза. Я хз, у меня из GTK софта только nautilus и firefox, остальное бесполезное напрочь.

Экран случайно не на 40Hz?

На 120Hz на всех трёх.

На 120Hz на всех трёх.

120 = 40 * 3

Наверняка у тебя в GTK3 только каждый третий кадр отрисовывается.

И почему-то именно на 40Hz, что не совпадает и никогда не совпадало с частотой вообще чего-либо.

Не редкость. В QEMU для gtk display захардкожена refresh rate 33Hz, баг висит годами, хорошего способа менять частоту не предусмотрено.

На gtk3 уже довольно мало софта моего осталось, но учитывая что раньше гном был заметно тормозным возможно в нём так и было. (всё равно не такой тормозной как kde на иксах)

тормозит как сучка

Как сучка - течёт. Тормозит - как гном.

Как сучка - течёт. Тормозит - как гном.

Окей, тормозит как умственно-отсталая сучка.

На gtk3 уже довольно мало софта моего осталось

Весь софт с GTK, который у меня установлен сейчас, именно что на GTK3: Firefox, Emacs, GIMP (лол), всякая срань с электроном (да, там GTK3). А вот на GTK4 у меня в системе нет буквально вообще нихрена.

(всё равно не такой тормозной как kde на иксах)

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

Я бы не учитывал firefox, emacs и электрон приложения т.к. наверняка они сами рисуют все свои вещи и потому на них скорее всего не накладываются тормоза gtk3. Про gimp уже не уверен, скорее всего он сильно зависим.

Если вы не видите тормоза kde на иксах то это отлично, вы сможете перейти на wayland и kde6 значительно позже когда оно перестанет падать. Я к сожалению вижу и потому на wayland еще с первых версий swaywm.

Я бы не учитывал firefox, emacs и электрон приложения т.к. наверняка они сами рисуют все свои вещи и потому на них скорее всего не накладываются тормоза gtk3.

Ну, да. Всё так. Они используют GTK только ради управления окнами и вывода на экран.

Другой вопрос в том, что зачем вообще GTK3 писали таким тормозным? GTK2 вот был норм.

вы сможете перейти на wayland и kde6 значительно позже когда оно перестанет падать.

Я не смогу перейти на Wayland, пока в Wayland не запилят пачку нужных мне протоколов (ext-placement, wlr-foreign-toplevel и ещё несколько) и эти протоколы на запилят в KWin и в весь софт, который я использую. То есть, глядя на чудовищный анал карнавал с цирковыми клоунами-гномами в гитлабе freedesktop.org, этого не стоит ждать ещё лет 5 минимум.

Но при сравнении сеансов в Xorg и Wayland, с графикой от красных я правда разницы особо не вижу. С зелёными была, да, но это косяк их драйвера.

Вывод в терминал не имеет ничего общего с реальной жизнью?

Не подменяй понятия. Вывод такого объёма информации в терминал в каких кейсах имеет смысл?

Не подменяй понятия. Вывод такого объёма информации в терминал в каких кейсах имеет смысл?

Ты понимаешь что такое бенчмарк? Это когда ты берешь трубу, и суешь в неё все что лезет, чтобы было удобнее замерять. Терминалы будут тормозить одинаково, что на 650 мегабайтах, что на двух.

Вывод в терминал не имеет ничего общего с реальной жизнью?

Не подменяй понятия. Вывод такого объёма информации в терминал в каких кейсах имеет смысл?

Это бенчмарк, дядя. Бенчмарки сами по себе смысловой нагрузки не несут и нужны только чтобы протестировать код и/или железо. По результатам теста выяснено, что код в VTE сосёт и его писали криворукие дебилы.

Это бенчмарк, дядя. Бенчмарки сами по себе смысловой нагрузки не несут и нужны только чтобы протестировать код и/или железо. По результатам теста выяснено, что код в VTE сосёт и его писали криворукие дебилы.

Понятно. VTE плохо решает задачи бенчмарков. Я думал есть какие-то реальные кейсы из реального мира. Оказалось, просто кому-то нужен ещё один повод теребонькать на что-то.

Терминалы будут тормозить одинаково, что на 650 мегабайтах, что на двух.

Упростим задачу для альтернативно одарённых. Зачем кидать в терминал 2 мегабайта? Ты реально будешь их там читать?

Упростим задачу для альтернативно одарённых. Зачем кидать в терминал 2 мегабайта? Ты реально будешь их там читать?

Ага, например если я логи скроллю. Прикинь, так можно делать!

Понятно. VTE плохо решает задачи бенчмарков.

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

Ага, например если я логи скроллю. Прикинь, так можно делать!

Регулярно скроллю логи, но не в озвученном объёме. Никогда не приходилось скроллить 600+ метров логов за минуту с небольшим. Более того, никогда не испытывал потребности скроллить 600+ метров логов быстрее, чем за минуту.

Если уж мы не используем никакой софт для просмотра логов, то хотя бы less делает это занятие сильно удобней, так как в логах обычно ищется нечто конкретное (время события, какой-нибудь идентификатор). Естественно, для поиска проще использовать поиск в less, чем листать 600+ метров логов со скоростью в несколько секунд.

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

пуньк среньк можно less

Господи, тред про то, что VTE смешное убожество. выключай зануду.

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

Я это понимаю. Но эта оптимизация не влияет вообще ни на что. Разве что кто-то реально страдает, от того, что он не может читать логи со скоростью 40 мегабайт в секунду из-за медленного терминала.

Господи, тред про то, что VTE смешное убожество. выключай зануду.

Я пытаюсь понять почему смешное убожество. С твоих слов выходит, что потому, что сасает на выдуманных кейсах, не имеющих отношения к реальности.

Я пытаюсь понять почему смешное убожество. С твоих слов выходит, что потому, что сасает на выдуманных кейсах, не имеющих отношения к реальности.

Потому что баг из-за которогоо он медленне всех остальных терминалов в разы заключается в «мы воткнули sleep и оно тормозит».

Я это понимаю. Но эта оптимизация не влияет вообще ни на что.

Почему не влияет? Прикинь, если запустить этот же код на системе в 10 раз медленнее, на каком-нибудь атоме. Или если твоя система под нагрузкой. Ты же не хочешь, чтобы твой терминал был совсем тотальным лагалищем, пока ты в нём пытаешься прибить процесс, сожравший весь проц?

Потому что баг из-за которогоо он медленне всех остальных терминалов в разы заключается в «мы воткнули sleep и оно тормозит».

Потому что не баг, очевидно.

Потому что баг из-за которогоо он медленне всех остальных терминалов в разы заключается в «мы воткнули sleep и оно тормозит».

Потому что не баг, очевидно.

Тормоза и лагалище как фича программного продукта :DDDDD

Видимо, для пущей солидности, как в тех байках из начала 2000х.

Почему не влияет? Прикинь, если запустить этот же код на системе в 10 раз медленнее, на каком-нибудь атоме. Или если твоя система под нагрузкой. Ты же не хочешь, чтобы твой терминал был совсем тотальным лагалищем, пока ты в нём пытаешься прибить процесс, сожравший весь проц?

Ну я фиг знает. Вон там в статистике медленный при медленный xterm не проявляет проблемы. Конечно, если у кого-то система медленней третьего пентиума, им критично может быть, но надо реально смотреть.

Потому что не баг, очевидно.

Ограничить скорость работы ради ничего это не баг? А что это?

Почему не влияет? Прикинь, если запустить этот же код на системе в 10 раз медленнее, на каком-нибудь атоме. Или если твоя система под нагрузкой. Ты же не хочешь, чтобы твой терминал был совсем тотальным лагалищем, пока ты в нём пытаешься прибить процесс, сожравший весь проц?

Ну я фиг знает. Вон там в статистике медленный при медленный xterm не проявляет проблемы. Конечно, если у кого-то система медленней третьего пентиума, им критично может быть, но надо реально смотреть.

Это два разных бенча: латентность и пропускная способность. У xterm всё хорошо с первым, но плохо со вторым. С другой стороны, я так прозреваю, там в размер буфера упирается всё, так что поправить не проблема.

Но я не знаю почти никого кто бы xterm пользовался в принципе, кроме пары лоровских шизоидов. Это как сравнивать производительность WM c TWM каким-нибудь.

Перепроверил на 622mb файле с lorem ipsum:

• gnome-console 46.0: 6.08s
• konsole 24.02.1: 13.98s
• alacritty 0.13.2: 6.98s.

Походу теперь остальные терминалы медленные и надо бежать создавать багрепорты для их бездарей-разрабов.

У foot 2.76s, но он походу создавался как раз для чтения логов со скоростью 200мбс, т.к. до сих пор нет даже поддержки лигатур и автор 4 года уже говорит что не знает как их добавить не замедлив терминал.

У foot 2.76s, но он походу создавался как раз для чтения логов со скоростью 200мбс, т.к. до сих пор нет даже поддержки лигатур и автор 4 года уже говорит что не знает как их добавить не замедлив терминал.

Зато там есть установка app_id и прочего. Лигатуры нахрен не нужны.

Ну и будем фактологически точны:

If someone else wants to have a go at this, please go ahead. I’ll be happy to assist. For a PR to get merged, its performance impact would have to be very low though. If that cannot be done, then a runtime or compile time option may be warranted.

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

У foot 2.76s, но он походу создавался как раз для чтения логов со скоростью 200мбс, т.к. до сих пор нет даже поддержки лигатур и автор 4 года уже говорит что не знает как их добавить не замедлив терминал.

Зато там есть установка app_id и прочего. Лигатуры нахрен не нужны.

Лигатуры – прикольная тема. В редакторе, но не в терминале.

Лигатуры – прикольная тема. В редакторе, но не в терминале.

Ну foot юзает много задротов с nvim в терминале, но чот вот никому пока не понадобилось. Вероятно все кому надо, используют vscode.

Лигатуры – прикольная тема. В редакторе, но не в терминале.

Ну foot юзает много задротов с nvim в терминале, но чот вот никому пока не понадобилось. Вероятно все кому надо, используют vscode.

Или emacs лол. Лигатуры классно работают в язычках типа хачкелля, где есть куча операторов. В сишке и подобных это в основном не слишком нужно.

Не увидел даже issue про app_id на gnome-console, оно точно вам нужно?

49 лайков тут говорит о том что всё таки понадобилось.

Не увидел даже issue про app_id на gnome-console, оно точно вам нужно?

Ага. Это позволяет запустить какую-нибудь консольную срань в терминале и видеть ее в доке как приложение, а не ещё один терминал.

49 лайков тут говорит о том что всё таки понадобилось.

49 лайков и ни одного пулл-реквеста. Значит не так сильно-то и понадобилось.