Біздің аударма бюросынан бірер сөз: әдетте әрбір адам соңғы материалдар мен басылымдарды аударуға ұмтылады, біз де бұдан тыс емеспіз. Бірақ терминалдар аптасына бір рет жаңартылатын нәрсе емес. Сондықтан біз сіздерге 2018 жылдың көктемінде жарияланған Антуан Бопрдің мақаласын аудардық: қазіргі заманғы стандарттар бойынша айтарлықтай «жасына» қарамастан, біздің ойымызша, материал өзінің өзектілігін мүлде жоғалтқан жоқ. Сонымен қатар, бұл бастапқыда екі мақаланың сериясы болды, бірақ біз оларды бір үлкен постқа біріктіруді шештік.
Терминалдардың компьютер тарихында алатын орны ерекше, бірақ соңғы онжылдықтарда олар графикалық интерфейстер барлық жерде таралғандықтан командалық жолдың жанында өмір сүруге мәжбүр болды. өздерінің орнын ауыстырды , бұл өз кезегінде перфокарталар мен ауыстырып қосқыштар негізіндегі жүйелердің модификациясы болды. Заманауи дистрибутивтер барлық пішіндер мен түстердің әртүрлі терминалдық эмуляторларымен келеді. Көптеген адамдар жұмыс ортасымен қамтамасыз етілген стандартты терминалға қанағаттанғанымен, кейбіреулер өздерінің сүйікті қабығын немесе мәтіндік редакторын іске қосу үшін экзотикалық бағдарламалық құралды мақтанышпен пайдаланады. Бірақ, осы мақаладан көретініміздей, барлық терминалдар бірдей кескінде жасалмаған: олар функционалдылық, өлшем және өнімділік бойынша айтарлықтай ерекшеленеді.
Кейбір терминалдарда таңқаларлық қауіпсіздік саңылаулары бар, сонымен қатар көпшілігінде қойынды интерфейсін қолдаудан сценарий жазуға дейін мүлдем басқа функциялар жиынтығы бар. Дегенмен біз , бұл мақала оқырмандарға 2018 жылы қандай терминалды пайдалану керектігін анықтауға көмектесетін алдыңғы материалдың жаңартылуы. Мақаланың бірінші жартысында мүмкіндіктер салыстырылады, ал екінші жартысында өнімділік бағаланады.
Міне, мен қараған терминалдар:
Бұл соңғы нұсқалар болмауы мүмкін, өйткені мен жазу кезінде тұрақты құрастырулармен шектелдім, оны Debian 9 немесе Fedora 27-де шығара алдым. Жалғыз ерекшелік - Alacritty. Бұл GPU-тездетілген терминалдардың ұрпағы және бұл тапсырма үшін әдеттен тыс және жаңа тілде жазылған - Rust. Мен шолуымнан веб-терминалдарды алып тастадым (оның ішінде ), өйткені алдын ала сынақтар олардың өте нашар өнімділігін көрсетті.
Юникодты қолдау
Мен сынақтарымды Юникод қолдауымен бастадым. Терминалдардың бірінші сынағы Юникод жолын көрсету болды : “é, Δ, И, ק, م, ๗, あ, 叶, 葉 және 말.” Бұл қарапайым сынақ терминалдың бүкіл әлем бойынша дұрыс жұмыс істей алатындығын көрсетеді. xterm терминалы араб таңбасын көрсетпейді әдепкі конфигурацияда:
Әдепкі бойынша, xterm классикалық «бекітілген» қаріпті пайдаланады, ол сәйкес , «1997 жылдан бері Юникодтың елеулі қамтуы» бар. Бұл қаріпте таңбаның бос жақтау ретінде пайда болуына себеп болатын бірдеңе бар және мәтін қаріпі 20+ нүктеге дейін ұлғайтылған кезде ғана таңба дұрыс көрсетіле бастайды. Дегенмен, бұл «түзету» басқа Юникод таңбаларының дисплейін бұзады:
Бұл скриншоттар Fedora 27-де түсірілді, өйткені ол Debian 9-ға қарағанда жақсы нәтиже берді, мұнда терминалдардың кейбір ескі нұсқалары (әсіресе mlterm) қаріптерді дұрыс өңдей алмады. Бақытымызға орай, бұл кейінгі нұсқаларда түзетілді.
Енді жолдың xterm-де қалай көрсетілетініне назар аударыңыз. Мем символы және одан кейінгі семит екені белгілі болды RTL стиліндегі сценарийлерді қараңыз (), техникалық жағынан олар оңнан солға қарай көрсетілуі керек. Firefox 57 сияқты веб-шолғыштар жоғарыдағы жолды дұрыс өңдейді. RTL мәтінінің қарапайым нұсқасы - бұл «иврит тілінде (). былай дейді:
«Көптеген компьютерлік бағдарламалар екі жақты мәтінді дұрыс көрсете алмайды. Мысалы, «Сара» еврей атауы sin (ש) (оң жақта пайда болады), содан кейін resh (ר) және соңында ол (ה) (сол жақта пайда болуы керек) таңбаларынан тұрады».
Көптеген терминалдар бұл сынақтан өтпейді: Alacritty, VTE-ден алынған Gnome және XFCE терминалдары, urxvt, st және xterm дисплейі «Sara» кері тәртіпте, біз атауды «Арас» деп жазғандай.
Екі жақты мәтіндердің тағы бір мәселесі - оларды қандай да бір жолмен туралау қажет, әсіресе RTL және LTR мәтіндерін араластыру кезінде. RTL сценарийлері терминал терезесінің оң жағынан іске қосылуы керек, бірақ LTR English стандартына сай келетін терминалдар үшін не болуы керек? Олардың көпшілігінде арнайы механизмдер жоқ және барлық мәтінді солға туралайды (соның ішінде Konsole). Ерекшеліктер стандарттарға сәйкес келетін және осындай сызықтарды оң жаққа туралайтын pterm және mlterm болып табылады.
Кірістіруден қорғау
Мен анықтаған келесі маңызды мүмкіндік - кірістіруге қарсы қорғаныс. Кеңінен белгілі болғанымен, келесідей емлелер:
$ curl http://example.com/ | shкодты орындаудың push пәрмендері болып табылады, тіпті мұқият тексеруден кейін де веб-шолғыштан көшіру және қою кезінде жасырын пәрмендер консольге жасырын түрде енуі мүмкін екенін аз адамдар біледі. пәрменнің қаншалықты зиянсыз екенін тамаша көрсетеді:
git clone git: //git.kernel.org/pub/scm/utils/kup/kup.gitHorn веб-сайтынан терминалға қою кезінде мұндай ыңғайсыздыққа айналады:
git clone /dev/null;
clear;
echo -n "Hello ";
whoami|tr -d 'n';
echo -e '!nThat was a bad idea. Don'"'"'t copy code from websites you don'"'"'t trust!
Here'"'"'s the first line of your /etc/passwd: ';
head -n1 /etc/passwd
git clone git://git.kernel.org/pub/scm/utils/kup/kup.gitБұл қалай жұмыс істейді? Зиянды код блокқа енгізілген , ол CSS көмегімен пайдаланушы көрінісінен шығарылады.
мұндай шабуылдарды бейтараптандыруға арналғаны анық. Бұл режимде терминалдар қабықшаға мәтіннің шығу тегі туралы хабарлау үшін қойылған мәтінді арнайы қашу тізбегі жұбына қосады. Бұл қабықшаға қойылған мәтінде болуы мүмкін арнайы таңбаларды елемеуі мүмкін екенін айтады. Құрметті xterm-ге қайта оралған барлық терминалдар бұл мүмкіндікті қолдайды, бірақ жақшаланған режимде қою терминалда жұмыс істейтін қабық немесе қолданбаның қолдауын қажет етеді. Мысалы, бағдарламалық жасақтаманы пайдалану (сол Bash), файл қажет ~/.inputrc:
set enable-bracketed-paste onӨкінішке орай, Хорнның сынақ сайты мәтінді пішімдеу арқылы бұл қорғауды айналып өту және оған жақша режимін мерзімінен бұрын қолдануды көрсетеді. Бұл жұмыс істейді, себебі кейбір терминалдар өздерін қосудан бұрын шығу ретін дұрыс сүзбейді. Мысалы, менде консоль сынақтарын дұрыс конфигурациямен де сәтті аяқтай алмадым .inputrc файл. Бұл қолдау көрсетілмейтін қолданба немесе қате конфигурацияланған қабық салдарынан жүйе конфигурациясын оңай бұза алатыныңызды білдіреді. Бұл әсіресе қашықтағы серверлерге кіру кезінде қауіпті, мұнда мұқият конфигурациялау жұмыстары сирек кездеседі, әсіресе сізде мұндай қашықтағы машиналар көп болса.
Бұл мәселенің жақсы шешімі - терминал үшін қоюды растау плагині urxvt, ол жаңа жолдарды қамтитын кез келген мәтінді енгізуге рұқсат сұрайды. Мен Horn сипаттаған мәтіндік шабуыл үшін қауіпсіз опцияны таппадым.
Қойындылар мен профильдер
Қазір танымал мүмкіндік - қойынды интерфейсіне қолдау көрсету, оны біз бірнеше терминалдардан тұратын бір терминал терезесі ретінде анықтаймыз. Бұл функция әртүрлі терминалдар үшін ерекшеленеді және дәстүрлі xterm терминалдары қойындыларды мүлде қолдамаса да, Xfce Terminal, GNOME Terminal және Konsole сияқты заманауи терминалдық нұсқаларда бұл функция бар. Urxvt қойындыларды да қолдайды, бірақ егер сіз плагинді пайдалансаңыз ғана. Бірақ қойындыларды қолдаудың өзі тұрғысынан Терминатор сөзсіз көшбасшы: ол қойындыларды қолдап қана қоймайды, сонымен қатар терминалдарды кез келген ретпен реттей алады (төмендегі суретті қараңыз).
Терминатордың тағы бір ерекшелігі - бұл қойындыларды бірге «топтастыру» және бір уақытта бірнеше терминалдарға бірдей пернелерді басу мүмкіндігі, бұл бір уақытта бірнеше серверлерде жаппай операцияларды орындауға арналған қарапайым құралды қамтамасыз етеді. Ұқсас мүмкіндік Konsole бағдарламасында да жүзеге асырылады. Бұл мүмкіндікті басқа терминалдарда пайдалану үшін, сияқты үшінші тарап бағдарламалық құралын пайдалану керек , немесе .
Қойындылар әсіресе профильдермен жұптастырылған кезде жақсы жұмыс істейді: мысалы, сізде электрондық пошта үшін бір қойынды, сөйлесу үшін басқа қойынды болуы мүмкін және т.б. Бұған Konsole терминалы және GNOME терминалы жақсы қолдау көрсетеді. Екеуі де әрбір қойындыға өз профилін автоматты түрде іске қосуға мүмкіндік береді. Терминатор профильдерді де қолдайды, бірақ белгілі бір қойындыны ашқан кезде белгілі бір бағдарламаларды автоматты түрде іске қосу жолын таба алмадым. Басқа терминалдарда «профиль» ұғымы мүлдем жоқ.
Руфельдер
Осы мақаланың бірінші бөлігінде мен қарастыратын соңғы нәрсе - терминалдардың сыртқы түрі. Мысалы, GNOME, Xfce және urxvt мөлдірлікті қолдайды, бірақ жақында фондық кескіндерге қолдау көрсетуді тоқтатты, бұл кейбір пайдаланушыларды терминалға ауысуға мәжбүр етті. . Жеке өзім оған ризамын және бұл қарапайым X ресурстар, ол urxvt үшін фондық түстердің негізгі жинағын орнатады. Дегенмен, стандартты емес түс тақырыптары да қиындықтар тудыруы мүмкін. Мысалы, қолданбалармен и , өйткені олар өздерінің түстерін пайдаланады.
түстерді қолдамады, ал жаңалары жиі 256 түсті палитрамен шектелді. Терминалдарын, қабықша шақыруларын немесе күй жолақтарын күрделі жолдармен стильдейтін озық пайдаланушылар үшін тітіркендіргіш шектеу болуы мүмкін. қай терминалдарда «True Color» қолдауы бар екенін бақылайды. Менің сынақтарым st, Alacritty және VTE негізіндегі терминалдар True Color-ты тамаша қолдайтынын растайды. Басқа терминалдар осыған байланысты өте жақсы емес және шын мәнінде, тіпті 256 түсті көрсетпейді. Төменде GNOME терминалдарындағы True Color қолдауы, st және xterm, 256 түс палитрасымен жақсы жұмыс істейді және urxvt арасындағы айырмашылықты көре аласыз, бұл сынақтан өтіп қана қоймайды, тіпті олардың орнына кейбір жыпылықтайтын таңбаларды көрсетеді.
Кейбір терминалдар сілтемелерді басуға болатын ету үшін URL үлгілері үшін мәтінді талдайды. Бұл VTE-ден алынған барлық терминалдарға қатысты, ал urxvt URL мекенжайларын бір рет басу немесе пернелер тіркесімін пайдалану арқылы түрлендіретін арнайы плагинді қажет етеді. Мен тексерген басқа терминалдар URL мекенжайларын басқа жолдармен көрсетеді.
Соңында, терминалдардағы жаңа тренд - айналдыру буферінің қосымша мүмкіндігі. Мысалы, st-де айналдыру буфері жоқ; пайдаланушы tmux және сияқты терминалды мультиплексорды пайдаланады деп болжанады .
Alacritty-де кері айналдыру буферлері жоқ, бірақ пайдаланушылардың осы тақырып бойынша «кеңінен кері байланысы» арқасында оны қолдау. Осы бастаулардан басқа, мен сынаған әрбір терминал кері айналдыруды қолдайды.
Аралық есептер
Материалдың екінші бөлігінде (Түпнұсқада бұл екі түрлі мақала болды - шамамен. жолақ) өнімділікті, жадты пайдалануды және кешігуді салыстырамыз. Бірақ біз қазірдің өзінде қарастырылып отырған терминалдардың кейбірінде елеулі кемшіліктер бар екенін көріп отырмыз. Мысалы, RTL сценарийлерімен үнемі жұмыс істейтін пайдаланушылар mlterm және pterm қарастырғысы келуі мүмкін, өйткені олар басқаларға қарағанда ұқсас тапсырмаларды жақсырақ орындайды. Консоль де жақсы өнер көрсетті. RTL сценарийлерімен жұмыс істемейтін пайдаланушылар басқа нәрсені таңдауы мүмкін.
Зиянды кодты енгізуден қорғау тұрғысынан urxvt шабуылдың осы түрінен қорғауды арнайы енгізуімен ерекшеленеді, бұл маған сөзсіз ыңғайлы болып көрінеді. Кейбір қоңыраулар мен ысқырықтарды іздейтіндер үшін Konsole қарауға тұрарлық. Соңында, VTE түс қолдауына, URL мекенжайын тануға және т.б. кепілдік беретін терминалдар үшін тамаша база екенін атап өткен жөн. Бір қарағанда, сүйікті ортаңызбен бірге келетін әдепкі терминал барлық талаптарға сай болуы мүмкін, бірақ өнімділікті түсінгенше бұл сұрақты ашық қалдырайық.
Әңгімені жалғастырайық
Тұтастай алғанда, терминалдардың өнімділігі өздігінен қиын мәселе болып көрінуі мүмкін, бірақ белгілі болғандай, олардың кейбіреулері осындай іргелі типтегі бағдарламалық қамтамасыз ету үшін таңқаларлық жоғары кідіріс көрсетеді. Сондай-ақ келесіде біз дәстүрлі түрде «жылдамдық» деп аталатын нәрсені (шын мәнінде, бұл айналдыру жылдамдығы) және терминалдың жадты тұтынуын қарастырамыз (бұл бүгінгі күні ондаған жылдар бұрынғыдай маңызды емес екенін ескертеміз).
Кешіктірілді
Терминалдың өнімділігін мұқият зерттегеннен кейін мен осыған байланысты ең маңызды параметр кідіріс (пинг) болып табылады деген қорытындыға келдім. Өз мақаласында Павел Фатин әртүрлі мәтіндік редакторлардың кешігуіне қарап, осыған байланысты терминалдар ең жылдам мәтіндік редакторларға қарағанда баяу болуы мүмкін екенін айтты. Дәл осы кеңес мені өзімнің жеке сынақтарымды жүргізуге және осы мақаланы жазуға әкелді.
Бірақ кідіріс дегеніміз не және ол неліктен маңызды? Фатин өз мақаласында оны «пернені басу мен сәйкес экранды жаңарту арасындағы кешігу» деп анықтады және дәйексөз келтірді. , онда былай делінген: «Компьютер дисплейіндегі визуалды кері байланыстың кешігуі терушінің мінез-құлқы мен қанағаттанушылығына маңызды әсер етеді».
Фатин бұл пингтің қанағаттанудан гөрі тереңірек салдары бар екенін түсіндіреді: «теру баяулайды, қателер көп болады, көз бен бұлшықет кернеуі артады». Басқаша айтқанда, үлкен кідіріс теру қателеріне, сонымен қатар код сапасының төмендеуіне әкелуі мүмкін, себебі бұл миға қосымша когнитивті жүктеме әкеледі. Бірақ одан да сорақысы, пинг «көз бен бұлшықет кернеуін арттырады», бұл дегенді білдіретін сияқты. болашақта (Шамасы, автор көздің бұлшық еттерінің, арқаның, қолдың және, әрине, көру проблемаларын білдіреді - шамамен. жолақ) қайталанатын стресске байланысты.
Бұл әсерлердің кейбірі ұзақ уақыт бойы белгілі және нәтижелері 1976 жылы Ergonomics журналында жарияланған 100 миллисекундтық кідіріс «теру жылдамдығын айтарлықтай төмендетеді» дейді. Жақында GNOME пайдаланушы нұсқаулығы ұсынылды 10 миллисекундта, ал әрі қарай жүрсеңіз, онда 1 миллисекундтың идеалды екенін көрсетеді.
Фатин өз сынақтарын мәтіндік редакторларда жүргізді; деп аталатын портативті аспапты жасады , оны мен терминал эмуляторларында пингті сынау үшін пайдаландым. Сынақ модельдеу режимінде жүргізілгенін есте сақтаңыз: іс жүзінде біз кіріс (пернетақта, USB контроллері және т.б.) және шығыс (бейне карта буфері, монитор) кешігуін ескеруіміз керек. Фатиннің айтуынша, әдеттегі конфигурацияларда ол шамамен 20 мс құрайды. Егер сізде ойын жабдықтары болса, сіз бұл көрсеткішке небәрі 3 миллисекундта қол жеткізе аласыз. Бізде мұндай жылдам аппараттық құрал бұрыннан бар болғандықтан, қолданбаға өзінің кідіріс уақытын қосудың қажеті жоқ. Фатиннің мақсаты - қолданбаның кешігуін 1 миллисекундқа жеткізу немесе тіпті онсыз теруге қол жеткізу сияқты .
Міне, менің өлшеулерімнің нәтижелері, сондай-ақ Фатиннің кейбір нәтижелері, менің экспериментім оның сынақтарымен келісетінін көрсету үшін:
Мені таң қалдырған бірінші нәрсе xterm және mlterm сияқты ескі бағдарламалардың жақсырақ жауап беру уақыты болды. Ең нашар регистрдің кешігуімен (2,4 мс) олар ең жылдам заманауи терминалға қарағанда жақсы жұмыс істеді (st үшін 10,6 мс). Ешбір заманауи терминал 10 миллисекунд шегінен төмен түспейді. Атап айтқанда, Alacritty «ең жылдам терминал эмуляторы» талаптарын қанағаттандыра алмайды, дегенмен оның ұпайлары 2017 жылы алғашқы шолудан кейін жақсарды. Шынында да, жобаның авторлары және дисплейді жақсарту үшін жұмыс істеуде. Сондай-ақ, GTK3 қолданатын Vim оның GTK2 аналогына қарағанда баяуырақ екенін атап өткен жөн. Бұдан GTK3 қосымша кідіріс жасайды деген қорытынды жасауға болады және бұл оны пайдаланатын барлық басқа терминалдарда (Terminator, Xfce4 Terminal және GNOME Terminal) көрінеді.
Дегенмен, айырмашылықтар көзге байқалмауы мүмкін. Фатин түсіндіргендей, «бұл сізге әсер етуі үшін кешіктіруді білудің қажеті жоқ». Фатин сонымен қатар стандартты ауытқу туралы ескертеді: «кешіктірілген кез келген бұзылулар (дірілдеу) олардың болжау мүмкін еместігіне байланысты қосымша стресс тудырады».
Жоғарыдағы график таза Debian 9 (созылу) арқылы алынған . Бұл орта кідіріс сынақтарында ең жақсы нәтижелерді береді. Белгілі болғандай, GNOME барлық өлшемдер үшін 20 мс қосымша пинг жасайды. Мұның мүмкін түсіндірмесі - кіріс оқиғаларын синхронды өңдеуі бар бағдарламалардың болуы. Фатин мұндай жағдайға мысал келтіреді , ол барлық кіріс оқиғаларын синхронды өңдеу арқылы кідіріс қосады. Әдепкі бойынша GNOME сонымен қатар терезе менеджерімен бірге келеді , бұл пингке әсер ететін және кем дегенде 8 миллисекундтық кідіріс қосатын қосымша буферлеу қабатын жасайды.
Айналдыру жылдамдығы
Келесі сынақ - экранда мәтіннің үлкен көлемін көрсету кезінде терминалдың бетті қаншалықты жылдам айналдыра алатынын өлшейтін дәстүрлі «жылдамдық» немесе «өткізу қабілеті» сынағы. Сынақтың механикасы әртүрлі; бастапқы сынақ seq пәрменін пайдаланып бірдей мәтіндік жолды жасау болды. Басқа сынақтарға бірнеше рет қайталанатын Томас Э . Терминал өнімділігінің басқа шолуында cat арқылы терминалға шығарылатын кездейсоқ байттардың base32 кодталған жолын пайдаланады. Луу мұндай сынақты «ойлай алатындай пайдасыз эталон» деп санайды және оның орнына терминалдық жауапты негізгі метрика ретінде пайдалануды ұсынады. Сондай-ақ Дики өзінің тестін жаңылыс деп атайды. Дегенмен, екі автор да терминал терезесінің өткізу қабілеттілігі мәселе болуы мүмкін екенін мойындайды. Луу үлкен файлдарды көрсету кезінде Emacs Eshell қатып қалуын анықтады, ал Дикки xtrerm визуалды баяулығынан құтылу үшін терминалды оңтайландырды. Сонымен, бұл сынақтың әлі де біраз артықшылығы бар, бірақ көрсету процесі терминалдан терминалға өте әртүрлі болғандықтан, оны басқа параметрлерді тексеру үшін сынақ құрамдас бөлігі ретінде де пайдалануға болады.
Мұнда біз rxvt және st-тің бәсекелестіктен озып шыққанын, одан кейін өнімділікке назар аудара отырып жасалған әлдеқайда жаңа Alacritty-ді көреміз. Одан кейін Xfce (VTE отбасы) және Konsole, олар екі есе дерлік жылдам. Соңғысы - xterm, ол rxvt-тен бес есе баяу. Сынақ кезінде xterm де қатты толқындады, бұл мәтінді бір жол болса да көруді қиындатады. Консоль жылдам болды, бірақ кейде қиын болды: дисплей оқтын-оқтын қатып қалады, ішінара мәтінді көрсетеді немесе оны мүлдем көрсетпейді. Басқа терминалдар жолдарды анық көрсетті, соның ішінде st, Alacritty және rxvt.
Дикки өнімділік айырмашылықтары әртүрлі терминалдардағы айналдыру буферлерінің дизайнына байланысты деп түсіндіреді. Атап айтқанда, ол rxvt және басқа терминалдарды «жалпы ережелерді сақтамайды» деп айыптайды:
«Xterm-ден айырмашылығы, rxvt барлық жаңартуларды көрсетуге әрекет жасамады. Егер ол артта қалса, қуып жету үшін кейбір жаңартулардан бас тартады. Бұл ішкі жадты ұйымдастыруға қарағанда айқын айналдыру жылдамдығына көбірек әсер етті. Бір кемшілігі ASCII анимациясының нақты еместігі болды».
Осы қабылданған xterm баяулығын түзету үшін Дики ресурсты пайдалануды ұсынады , ағынға ілесу үшін xterm кейбір экран жаңартуларын алып тастауға мүмкіндік береді. Менің сынақтарым fastScroll өнімділігін жақсартатынын және xterm-ді rxvt-мен теңестіретінін растайды. Дегенмен, бұл өте өрескел балдақ, Диккидің өзі түсіндіреді: «кейде xterm - konsole сияқты - кейбіреулері жойылғаннан кейін экран жаңартуларының жаңа жиынтығын күту кезінде тоқтап қалатын сияқты». Осыған байланысты, басқа терминалдар жылдамдық пен дисплей тұтастығы арасындағы ең жақсы ымыраға келген сияқты.
Ресурстарды тұтыну
Айналдыру жылдамдығын өнімділік көрсеткіші ретінде қарастырудың мағынасы бар ма, жоқ па, бұл сынақ терминалдардағы жүктемені имитациялауға мүмкіндік береді, бұл өз кезегінде жад немесе дискіні пайдалану сияқты басқа параметрлерді өлшеуге мүмкіндік береді. Көрсеткіштер көрсетілген сынақты орындау арқылы алынды SEQ Python процесін бақылау астында. Ол есептегіш деректерін жинады үшін ru_maxrss, сомасы ru_oublock и ru_inblock және қарапайым таймер.
Бұл сынақта СТ 8 МБ жадты ең аз тұтынумен бірінші орынды алады, бұл дизайнның негізгі идеясы қарапайымдылық екенін ескерсек, таңқаларлық емес. mlterm, xterm және rxvt аздап көбірек тұтынады - шамамен 12 МБ. Тағы бір маңызды нәтиже - іске қосу үшін 30 МБ қажет Alacritty. Одан кейін 40-тан 60 МБ-қа дейінгі сандармен VTE отбасының терминалдары бар, бұл өте көп. Бұл тұтынуды бұл терминалдарда жоғары деңгейлі кітапханаларды пайдалану фактісімен түсіндіруге болады, мысалы, GTK. Консоль сынақтар кезінде 65 МБ жадты тұтынуымен соңғы орында келеді, дегенмен бұл оның мүмкіндіктерінің өте кең ауқымымен негізделуі мүмкін.
Он жыл бұрын алынған алдыңғы нәтижелермен салыстырғанда, барлық бағдарламалар жадты айтарлықтай көп тұтына бастады. Xterm бұрын 4 МБ талап ететін, бірақ енді іске қосу кезінде 15 МБ қажет. Rxvt үшін тұтынудың ұқсас өсуі бар, ол қазір қораптан 16 МБ қажет. Xfce терминалы 34 Мбайтты алады, бұл бұрынғыдан үш есе үлкен, бірақ GNOME терминалы бар болғаны 20 МБ қажет. Әрине, барлық алдыңғы сынақтар 32-биттік архитектурада жүргізілді. LCA 2012-де Rusty Russell , жадты тұтынудың ұлғаюын түсіндіре алатын көптеген нәзік себептер бар. Осыны айта отырып, біз қазір гигабайт жады бар уақытта өмір сүріп жатырмыз, сондықтан біз қандай да бір жолмен басқарамыз.
Дегенмен, терминал сияқты іргелі нәрсеге көбірек жадты бөлу ресурстарды ысырап ететінін сезбеймін. Бұл бағдарламалар ең кішкентайлардың ең кішісі болуы керек, кез келген «қорапта», тіпті аяқ киім қорабында да жұмыс істей алуы керек, егер біз оларды Linux жүйелерімен жабдықтау қажет болатын нүктеге келсек (және сіз солай болатынын білесіз) ). Бірақ бұл сандармен жадты пайдалану болашақта ең жеңіл және мүмкіндіктері шектеулі бірнеше терминалдардан басқа бірнеше терминалдар жұмыс істейтін кез келген ортада мәселеге айналады. Мұның орнын толтыру үшін GNOME Terminal, Konsole, urxvt, Terminator және Xfce Terminal жадты тұтынуды шектей отырып, бір процесс арқылы бірнеше терминалдарды басқаруға мүмкіндік беретін Daemon режиміне ие.
Тестілеу кезінде мен дискіні оқу-жазуға қатысты тағы бір күтпеген нәтижеге жеттім: мен бұл жерден ештеңе көрмеймін деп күткенмін, бірақ кейбір терминалдар дискіге ең көлемді деректерді жазатыны анықталды. Сонымен, VTE кітапханасы дискіде айналдыру буферін сақтайды (бұл мүмкіндік , және бұл әлі де болып жатыр). Бірақ ескі іске асырудан айырмашылығы, қазір бұл деректер AES256 GCM арқылы шифрланған (). Бірақ ақылға қонымды сұрақ туындайды: VTE кітапханасының ерекшелігі неде, ол іске асыруға стандартты емес тәсілді қажет етеді...
қорытынды
Мақаланың бірінші бөлігінде біз VTE негізіндегі терминалдарда жақсы мүмкіндіктер жиынтығы бар екенін анықтадық, бірақ қазір бұл кейбір өнімділік шығындарымен келетінін көреміз. Енді жад мәселесі емес, өйткені барлық VTE терминалдарын Daemon процесі арқылы басқаруға болады, бұл олардың аппетитін шектейді. Дегенмен, жедел жады мен ядро буферінің мөлшерінде физикалық шектеулері бар ескі жүйелер әлі де терминалдардың бұрынғы нұсқаларын қажет етуі мүмкін, өйткені олар ресурстарды айтарлықтай аз тұтынады. VTE терминалдары өткізу қабілеті (айналдыру) сынақтарында жақсы жұмыс істегенімен, олардың дисплей кідірісі GNOME пайдаланушы нұсқаулығында орнатылған шекті мәннен жоғары. VTE әзірлеушілері мұны ескеруі керек. Егер Linux-тың жаңадан келген пайдаланушылары үшін терминалға тап болмай қалмайтынын ескерсек, олар оны пайдаланушыға ыңғайлы ете алады. Тәжірибелі гектер үшін әдепкі терминалдан ауысу тіпті азырақ көздің шаршауын және ұзақ жұмыс сеанстарына байланысты болашақ жұмысқа байланысты жарақаттар мен ауруларды болдырмау мүмкіндігін білдіруі мүмкін. Өкінішке орай, тек ескі xterm және mlterm бізді 10 миллисекундтық сиқырлы пинг шегіне әкеледі, бұл көптеген адамдар үшін қолайсыз.
Эталондық өлшемдер сонымен қатар Linux графикалық орталарының дамуына байланысты әзірлеушілерге бірқатар ымыраға келуге тура келгенін көрсетті. Кейбір пайдаланушылар әдеттегі терезе менеджерлеріне қарағысы келуі мүмкін, себебі олар пингті айтарлықтай азайтуды қамтамасыз етеді. Өкінішке орай, Wayland үшін кешіктіруді өлшеу мүмкін болмады: мен пайдаланған Typometer бағдарламасы Wayland алдын алу үшін жасалған: басқа терезелерде тыңшылық. Мен Wayland құрастыру X.org-қа қарағанда жақсырақ жұмыс істейді деп үміттенемін және болашақта біреу осы ортада кешіктіруді өлшеудің жолын табады деп үміттенемін.
Ақпарат көзі: www.habr.com