LINUX.ORG.RU

Программы, которые не тормозят

 , ,


12

5

С каждым годом программы тормозят все больше, от базовых утилит, до операционных систем и bios.

Предлагаю составить список программ, которые работают быстро, или терпимо.

Но для начала я напишу то чего стоит избегать

  • qt5, qt6, gtk3, gtk4 они тормозят, открываются с задержкой, есть ощутимый лаг при взаимодействии
  • electron
  • wxWidgets если в качестве бекенда используется gtk3 или qt5
  • старые версии программ, например xfce до перехода на gtk3, или xpdf до перехода на qt5. они не тормозили, но они уже не развиваются, интереснее узнать что есть из живого, или хотя бы такого что будет легко установить без перекомпиляции

Программы которые работают терпимо

  • xfe файловый менеджер (не путать с xfce http://roland65.free.fr/xfe/ )
  • (x)nedit простой текстовый редактор c номерами строк и подсветкой
  • grafx2 рисовалка, ориентирована на pixelart
  • mpv просмотр видео
  • palemoon браузер. с отключенным javascript, ощущается приятно, открывает больше чем какой нибудь netsurf
  • OpenOffice офис. тормозит но тормозит намного быстрее чем LibreOffice
  • xdm дисплейный менеджер
  • jwm, icewm оконные менеджеры похожие на windows, быстрые и не требующие сложной настройки
  • cmus аудиоплеер с двухпанельностью. консольный что минус, но быстро работает с библиотекой, сканирует, поддерживает cp1251
  • mutt+msmtprc консольный почтовик, относительно легко настроить и управлять

Пользователь d советует рассмотреть проекты

  • suckless
  • pwmt

Пользователь xsaeta рекомендует

  • zzzfm двухпанельный файловый менеджер
  • nsxiv просмотрщик изображений
  • mpd для музыки
  • ClawsMail почтовик
  • приложения Trinity
  • приложения LXDE
  • Pidgin — мультипротокольный IM-клиент на GTK+2

Пользователь tiinn подсказывает XPaint программу для рисования

Пользователь posixbit рекомендует

  • SpaceFM (очень быстрый и мощный файловый менеджер GTK+ 2 с большим количеством плагинов).
  • Double Commamder (версия GTK+ 2; быстрый двухпанельный файловый менеджер, почти полная копия Total Commander).
  • Sylpheed (классический и самый быстрый почтовый клиент; GTK +2).
  • LillyTerm (терминал с настройкой через графический интерфейс на GTK+ 2), st (самый простой терминал; не использует Qt и GTK), Kitty (простой терминал, но с GPU-ускорением) {{MOPKOBKA: Kitty у меня тормозит}}.
  • Rainbow-CM, Parcelite (менеджеры буфера обмена на GTK+ 2).
  • Zathura-PDF-MUPDF (самая быстрая читалка PDF — именно эта версия с MuPDF, а не Poopler).
  • LXTask (диспетчер задач; можно собрать с GTK+ 2).
  • Cinelerra GG (самый быстрый, но довольно функциональный видеоредактор под Linux; не использует Qt и GTK).
  • GMPC (музыкальный плеер — быстрый и мощный графический клиент GTK+ 2 к mpd).
  • TransGUI (самый быстрый и лёгкий торрент-клиент; использует GTK+ 2, требует для работы установленный и запущенный transmission-daemon).
  • CudaText-GTK2 (довольно быстрый и развивающийся текстовый редактор, вдохновлённый SublimeText). {{MOPKOBKA: У меня тормозит}}
  • LiteXL (довольно быстрый текстовый редактор на Lua; не использует Qt и GTK). {{MOPKOBKA: на SDL2 думаю будет тормозить, не пробовал}}
  • Abiword (лёгкий и функциональный текстовый процессор) и Gnumeric (самый быстрый и функциональный табличный процессор под Linux; великолепная совместимость с xls/xlsx) — обе эти программы можно собрать с GTK+ 2. {{MOPKOBKA: У меня тормозит}}
  • Dia (лёгкий редактор диаграмм, схем и графиков; на GTK+ 2).
  • FreeOffice (самый быстрый офисный пакет под Linux, имеет хорошую совместимость с файлами Microsoft Office; использует Xlib, а не Qt или GTK).
  • ImageMagick-GUI (различные быстрые операции над изображениями; не использует Qt и GTK).
  • AzPainter (быстрый, но мощный графический редактор на Xlib).
  • Oculante (быстрый просмотрщик изображений; не использует Qt и GTK). {{MOPKOBKA: Rust}}
  • maim (простая, но гибкая утилита для создания скриншотов с настройкой через консольные команды; не использует GTK и Qt); {{MOPKOBKA: Не пробовал, но мне нравится scrot}}
  • Dunst (простейший центр уведомлений; не использует Qt и GTK).
  • FTP/SFTP-менеджер gFTP (GTK+ 2)
  • IRC-клиенты HexChat (GTK+ 2) и XChat-SE (Xlib) {{MOPKOBKA: HexChat все }}

Пользователь firkax советует свой WM https://dev.m1089.ru/fwmx

Коллективный анон советует

  • moc(p) - TUI
  • mpg123/ogg123 - CLI
  • xcalc - калькулятор {{MOPKOBKA: Входит в набор X11 Applications, там все хорошо работает, но не все актуально}}
  • https://codeberg.org/newsraft/newsraft - rss читалка

Пользователь vbcnthfkmnth123 рекомендует

Пользователь stabilitron рекомедует

  • ffplay - игрок видео, аудио, стримов, гифок, картинок и пр. {{MOPKOBKA: Программка проекта ffmpeg}}

Пользователь SPRATAY исползует

  • Bluetui - TUI for managing bluetooth on Linux
  • Lazygit - simple terminal UI for git commands

Якобы не тормозят, но у меня тормозят еще как

  • gpu ускоренные терминалы
  • xterm, rxvt, vte терминалы
  • AbiWord замена ворда
  • SublimeText текстовый редактор
  • vim, emacs в любом виде
★★★★

Последнее исправление: MOPKOBKA (всего исправлений: 24)

Ответ на: комментарий от posixbit

Лаг ввода формируется еще из разных мест. Частота опроса сенсора мыши не равно частота опроса кнопок мыши и тут может легко пойти разлад, хотя вроде бы что такое 7 миллисекунд разницы да? Вот только когда цель мечется влево-вправо это очень сильно влияет и не на быстрых мониторах, которые по-своему, но тоже влияют на общий лаг, так как чем быстрее монитор тем чаще опрос может попасть перед кадром. Вот только есть еще пара нюансов и один из них частота фактически съемки и он может быть как 150 раз в секунду, так и 750 раз в секунду, а это разница в 5 раз. И опрашивать сенсор, который фактически снимает с частотой 150 кадров с частотой выше 1000 герц просто бесполезно и ненужно. На винде то можно поднять частоту опроса составного устройства. На линуксе же вроде как только частоту опроса сенсора можно выставить до 1 миллисекунды или же 1000 герц. А клавиатура тоже лаг создает при вводе и часто там 120 герц реальная частота работы самих кнопок. Возможно поэтому так критична производительность самих программ чтобы этот лаг был поменьше. И ненужно быть киберспортсменом чтобы замечать эту разницу, ведь они тоже люди. Игры и так работают нереально быстро тратя минимум ресурсов на самом деле на саму игру. Это просто обзорщики тупые и не в курсе какой должна быть конфигурация ПК для игр чтобы снизить бесполезную нагрузку на ЦП и память чтобы отклик стал меньше. Можно конечно всякую муть обозвать как-то по-особому но в Quake Champions есть настройка или брать данные DirectX или напрямую игра это будет делать, что позднее сделали. И всякие типа технологии по сути ускоряют кривую работу через DirectX, что никак не влияет по сути на прямой ввод потому что все и так максимально реактивно. И 300 кадров что в CS2, что в Quake Champions вывозит и простая видеокарта. А замечать можно глазами и результатами. Если ты с ботами с монитором 60 герц стреляя только из одного вида оружия безостановочно в режиме Нечестивой троицы все 30 минут имеешь скажем 33% попаданий рельсы по маленькому чемпиону это не выдающийся показатель. А вот если у тебя 40% это уже довольно приличный результат, если это без увеличения на любом расстоянии. И вот тут ты можешь и не видеть конкретную работу, но результат может отличаться в большую сторону. Остальное не принципиально, ведь когда ты точно знаешь что рельса будет 50% или выше у тебя модель поведения сразу меняется с осторожной при 33% на достаточно уверенную. Можешь кстати сравнить количество своих попаданий в голову и подумать какого хрена в CS2 что ни лунь то бошкострел неписанный. Смысл один - попасть в голову. Вот включаешь режим мгновенной смерти и смотришь сколько реально у тебя попаданий в голову, а не то что валв нарисовали. С рельсы попасть то тяжело, не то что в голову - просто в чемпиона размером на 15% меньше уже тяжко попадать. Этот говеный самообман с хедшотами давно пора разоблачить посадим мамкиных хедшотеров в Quake Champions и поглядеть как они будут попадать. Там от силы несколько раз за сотню они могут попасть в реальности. Скорость кадров одинаковая может быть скажем те же 300 кадров. Я не знаю что они там подкрутили, но это аимботство ходячее, причем бошкострельное. И сразу миф про адских киберспортсменов развалится потому что большинство из них с вареными мозгами попадают как боги, если это не Quake.

anonymous
()
Ответ на: комментарий от posixbit

сравнил то же самое прямо сейчас:

foot:

$ time seq 1000000
...
seq 1000000  0.24s user 0.98s system 99% cpu 1.221 total

alacritty:

$ time seq 1000000
...
seq 1000000  0.20s user 0.93s system 99% cpu 1.132 total

как видим цифры почти одинаковые, при этом foot не использует GPU и весит гораздо меньше alacritty. Статистика в арче например:

Package Size: 	304.8 KB
Installed Size:	710.6 KB

vs

Package Size: 	2.5 MB
Installed Size:	8.6 MB
Lrrr ★★★★★
()
Ответ на: комментарий от Lrrr

Konsole

seq 1000000 0,01s user 0,40s system 96% cpu 0,423 total

Yaquake

seq 1000000 0,01s user 0,36s system 97% cpu 0,376 total

Kitty

real 0m0,281s user 0m0,003s sys 0m0,277s

Uxterm

real 0m0,412s user 0m0,007s sys 0m0,405s

LXterm

real 0m0,405s user 0m0,013s sys 0m0,295s

Alacritty

real 0m0,283s user 0m0,000s sys 0m0,283s

anonymous
()
Ответ на: комментарий от anonymous

Лол, ты хотел разницу на статической картинке получить? Разница заметна должна быть, тест специально для этого разработан, прям как tearing test который можно найти на ютубе. Но учитывая что у тебя ноутбук, возможно вмешиваются другие характеристики экрана, такие как время перехода пикселя, в ноутбуки понятное дело нормальное железо не ставят.

Первая картинка должна быть лучше чем две нижние, которые будут похожи на друг друга. 120 гц это конечно тоже мало, между тремя тормозами разницу определить сложнее чем между хорошим результатом и плохим.

MOPKOBKA ★★★★
() автор топика
Последнее исправление: MOPKOBKA (всего исправлений: 1)
Ответ на: комментарий от greenman

i3, 60 гц, 4 гб памяти. На том компьютере nedit летал, и сейчас летает. И как были заметны задержки в gtk3, так и сейчас заметны.

MOPKOBKA ★★★★
() автор топика
Последнее исправление: MOPKOBKA (всего исправлений: 1)

Все приложения tui(консольные), командные , либо имеют свою реализацию отрисовки на подобие mpv

Что конкретно я использую

Kitty

Nvim

MPV

Bluetui

Lazygit

В остальном к сожалению использую гуи основанные на qt или gtk

В большинстве терминал

SPRATAY ★★
()

Через программу Typometer протестировал некоторые редакторы и терминалы, тест заключается в вводе одного символа, а программа замеряет через сколько он появится

# Title					Min	Max	Avg	SD
XTerm + Compositing OFF			0,7	2,1	0,9	0,1
XTerm + Compositing ON			1,8	2,8	2,2	0,2
St + Compositing OFF			2,9	3,4	3,1	0,1
Xfce4-Terminal + Compositing OFF	26,3	27,9	26,9	0,3
Konsole + Compositing OFF		11,4	12,4	11,9	0,2
XNedit + Compositing OFF		0,7	1,2	0,9	0,1
Kate + Compositing OFF			1,1	2,1	1,4	0,1
gVim GTK3 + Compositing OFF		1,0	3,8	1,1	0,2
Mousepad + Compositing OFF		0,7	2,8	1,0	0,2
Vim XTerm + Compositing OFF		0,8	3,9	1,0	0,2
JB PyCharm + Compositing OFF		0,7	2,3	1,4	0,2

И для терминалов прогнал time seq 1000000

  • XTerm - 2,5s
  • Rxvt - 0,2s
  • Konsole - 0,6s
  • St - 0,4s
  • Xfce4-Terminal - 0,5s

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

Выводы такие, даже программы на Java как PyCharm могут иметь хороший инпут-лаг, и то что тест на один символ явно не дает понимания тормозит ли программа с выводом.

MOPKOBKA ★★★★
() автор топика
Последнее исправление: MOPKOBKA (всего исправлений: 4)

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

// gcc video.c $(pkg-config --libs --cflags sdl2) -o video
#include <string.h>
#include <time.h>
#include <SDL.h>

int main(int argc, char **argv)
{
	SDL_Init(SDL_INIT_VIDEO | SDL_INIT_EVENTS);
	SDL_Window *window = SDL_CreateWindow("", 100, 100, 1000, 1000, SDL_WINDOW_SHOWN);
	SDL_Renderer *render = SDL_CreateRenderer(window, -1, SDL_RENDERER_ACCELERATED);
	struct timespec t = { 0, 2000000 };
	for (;;) {
		SDL_SetRenderDrawColor(render, 255, 255, 255, 255);
		SDL_RenderClear(render);
		SDL_RenderPresent(render);

		SDL_SetRenderDrawColor(render, 0, 0, 0, 255);
		SDL_RenderClear(render);
		SDL_RenderPresent(render);

		nanosleep(&t, NULL);
		SDL_Event e;
		while (SDL_PollEvent(&e)) {
			if (e.type == SDL_QUIT) return 0;
		}
	}
	return 0;
}

// gcc term.c -lcurses -o term
#include <unistd.h>
#include <string.h>
#include <time.h>
#include <ncurses/ncurses.h>
#include <sys/ioctl.h>

int main(int argc, char **argv)
{
	int h, w;
	struct winsize size;
	ioctl(0, TIOCGWINSZ, (char *) &size);
	h = size.ws_row;
	w = size.ws_col;

	char buff1[h][w];
	char buff2[h][w];

	memset(buff1, '#', sizeof(buff1));
	memset(buff2, ' ', sizeof(buff2));
	for (int i = 0; i < h; i++) {
		buff1[i][w - 1] = '\n';
	       	buff2[i][w - 1] = '\n';	
	}
	struct timespec t = { 0, 2000000 };
	for (;;) {
		clear();
		write(1, buff1, sizeof(buff1));
		clear();
		write(1, buff2, sizeof(buff2));
		nanosleep(&t, NULL);
	}
	return 0;
}
  • rxvt нет мерцания
  • xterm нет мерцания
  • st нет мерцания
  • xfce4-terminal заметное мерцание
  • konsole заметное мерцание

Но xterm и другие терминалы точно иногда мерцают у меня даже на простом выводе вне этого теста, хотя в тесте все ок. Возможно придумаю тест который показывает проблемы Xterm.

MOPKOBKA ★★★★
() автор топика
Последнее исправление: MOPKOBKA (всего исправлений: 3)
Ответ на: комментарий от MOPKOBKA

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

dmitry237 ★★★★
()
Ответ на: комментарий от dmitry237

или вообще не выбирают, пользуются тем, что есть

Все так. Пользователи вообще редко в терминал заходят. Публикую эти тесты для себя и интересующихся.

MOPKOBKA ★★★★
() автор топика
Последнее исправление: MOPKOBKA (всего исправлений: 1)
Ответ на: комментарий от posixbit

Например, даже когда я удовлетворительно видел, я не мог отличить видео в 60 FPS и 140 FPS. Проводил различные слепые тесты. Вот просто не дано. И я подозреваю, что на такое способны лишь меньшинство — например, натренированные на это геймеры-киберспортсмены — а подавляющее большинство людей, как и я, не способно на это.

Да нет, я вот без проблем отличаю 60 от 120. При 120 меня укачивает и тянет блевать.

hateyoufeel ★★★★★
()