Ilang salita mula sa aming kawanihan ng pagsasalin: karaniwang lahat ay nagsusumikap na isalin ang pinakabagong mga materyales at publikasyon, at kami ay walang pagbubukod. Ngunit ang mga terminal ay hindi isang bagay na ina-update minsan sa isang linggo. Samakatuwid, isinalin namin para sa iyo ang isang artikulo ni Antoine Beaupré, na inilathala noong tagsibol ng 2018: sa kabila ng malaking "edad" nito ayon sa mga modernong pamantayan, sa aming opinyon, ang materyal ay hindi nawala ang kaugnayan nito. Bilang karagdagan, ito ay orihinal na serye ng dalawang artikulo, ngunit nagpasya kaming pagsamahin ang mga ito sa isang malaking post.
Ang mga terminal ay may isang espesyal na lugar sa kasaysayan ng computer, ngunit sa mga nakalipas na dekada sila ay pinilit na mabuhay sa tabi ng command line habang ang mga graphical na interface ay nagiging ubiquitous. pinalitan ang kanilang sarili , na, sa turn, ay isang pagbabago ng mga system batay sa mga punched card at toggle switch. Ang mga modernong distribusyon ay may kasamang iba't ibang terminal emulator ng lahat ng hugis at kulay. At habang marami ang kontento sa karaniwang terminal na ibinigay ng kanilang kapaligiran sa trabaho, ang ilan ay buong pagmamalaki na gumagamit ng talagang kakaibang software upang patakbuhin ang kanilang paboritong shell o text editor. Ngunit, tulad ng makikita natin mula sa artikulong ito, hindi lahat ng mga terminal ay nilikha sa parehong imahe: malaki ang pagkakaiba ng mga ito sa pag-andar, laki at pagganap.
Ang ilang mga terminal ay may mga nakakagulat na butas sa seguridad, at karamihan ay may ganap na magkakaibang hanay ng mga pag-andar, mula sa suporta para sa isang naka-tab na interface hanggang sa pag-script. Bagama't tayo , ang artikulong ito ay isang update ng nakaraang materyal na makakatulong sa mga mambabasa na matukoy kung aling terminal ang gagamitin sa 2018. Ang unang kalahati ng artikulo ay naghahambing ng mga tampok, at ang pangalawang kalahati ay sinusuri ang pagganap.
Narito ang mga terminal na sinuri ko:
Maaaring hindi ito ang pinakabagong mga bersyon, dahil limitado lang ako sa mga matatag na build sa oras ng pagsulat, na nagawa kong ilunsad sa Debian 9 o Fedora 27. Ang tanging exception ay Alacritty. Ito ay isang inapo ng GPU-accelerated na mga terminal at nakasulat sa isang hindi pangkaraniwang at bagong wika para sa gawaing ito - Rust. Ibinukod ko ang mga web terminal mula sa aking pagsusuri (kabilang ang mga nasa ), dahil ipinakita ng mga paunang pagsusulit ang kanilang napakahinang pagganap.
Suporta sa Unicode
Sinimulan ko ang aking mga pagsubok sa suporta ng Unicode. Ang unang pagsubok ng mga terminal ay upang ipakita ang Unicode string mula sa : “é, Δ, И, ק, م, ๗, あ, 叶, 葉 at 말.” Ang simpleng pagsubok na ito ay nagpapakita kung ang terminal ay maaaring gumana nang tama sa buong mundo. xterm terminal ay hindi nagpapakita ng Arabic character sa default na pagsasaayos:
Bilang default, ginagamit ng xterm ang klasikong "fixed" na font, na, ayon sa , ay may "malaking saklaw ng Unicode mula noong 1997". May nangyayari sa font na ito na nagiging sanhi ng paglitaw ng character bilang isang blangkong frame at kapag ang font ng teksto ay nadagdagan sa 20+ puntos na sa wakas ay magsisimulang magpakita ng tama ang karakter. Gayunpaman, sinira ng "pag-aayos" na ito ang pagpapakita ng iba pang mga karakter ng Unicode:
Ang mga screenshot na ito ay kinuha sa Fedora 27, dahil nagbigay ito ng mas mahusay na mga resulta kaysa sa Debian 9, kung saan ang ilang mga mas lumang bersyon ng mga terminal (partikular na mlterm) ay hindi maaaring humawak ng mga font nang maayos. Sa kabutihang palad ito ay naayos sa mga susunod na bersyon.
Ngayon pansinin kung paano ipinapakita ang linya sa xterm. Lumalabas na ang simbolo na Mem at ang sumusunod na Semitic sumangguni sa mga script ng istilo ng RTL (), kaya teknikal na dapat ipakita ang mga ito mula kanan hanggang kaliwa. Ang mga web browser tulad ng Firefox 57 ay pinangangasiwaan nang tama ang linya sa itaas. Ang isang mas simpleng bersyon ng RTL text ay ang salitang "" sa Hebrew (). sabi ng sumusunod:
“Maraming mga computer program ang hindi makapagpakita ng bidirectional na text ng tama. Halimbawa, ang pangalang Hebreo na "Sarah" ay binubuo ng mga character na sin (ש) (na lumalabas sa kanan), pagkatapos ay resh (ר) at panghuli siya (ה) (na dapat lumitaw sa kaliwa)."
Maraming terminal ang nabigo sa pagsusulit na ito: Alacritty, VTE-derived Gnome at XFCE terminals, urxvt, st at xterm display "Sara" sa reverse order, na parang isinulat namin ang pangalan bilang "Aras".
Ang isa pang problema sa mga bidirectional na teksto ay ang mga ito ay kailangang ihanay kahit papaano, lalo na pagdating sa paghahalo ng mga teksto ng RTL at LTR. Dapat tumakbo ang mga RTL script mula sa kanang bahagi ng terminal window, ngunit ano ang dapat mangyari para sa mga terminal na default sa LTR English? Karamihan sa kanila ay walang anumang mga espesyal na mekanismo at ihanay ang lahat ng teksto sa kaliwa (kabilang ang sa Konsole). Ang mga eksepsiyon ay pterm at mlterm, na sumusunod sa mga pamantayan at i-right-align ang mga naturang linya.
Proteksyon sa pagpasok
Ang susunod na kritikal na feature na natukoy ko ay ang anti-insertion protection. Kahit na ito ay malawak na kilala na ang mga spells tulad ng:
$ curl http://example.com/ | shay mga code execution push command, kakaunti ang nakakaalam na ang mga nakatagong command ay maaaring lumabas sa console kapag kinokopya at i-paste mula sa isang web browser, kahit na pagkatapos ng maingat na inspeksyon. napakatalino na nagpapakita kung gaano kawalang-hanggan ang utos:
git clone git: //git.kernel.org/pub/scm/utils/kup/kup.gitnagiging isang istorbo kapag na-paste mula sa website ni Horn sa terminal:
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.gitPaano ito gumagana? Kasama ang malisyosong code sa block , na inalis sa view ng user gamit ang CSS.
ay malinaw na idinisenyo upang neutralisahin ang mga naturang pag-atake. Sa mode na ito, isinasama ng mga terminal ang naka-paste na text sa isang pares ng mga espesyal na sequence ng pagtakas upang sabihin sa shell ang tungkol sa pinagmulan ng text. Sinasabi nito sa shell na maaari nitong balewalain ang mga espesyal na character na maaaring naglalaman ng naka-paste na teksto. Sinusuportahan ng lahat ng terminal pabalik sa kagalang-galang na xterm ang feature na ito, ngunit ang pag-paste sa Bracketed mode ay nangangailangan ng suporta mula sa shell o application na tumatakbo sa terminal. Halimbawa, gamit ang software (parehong Bash), kailangan ng file ~/.inputrc:
set enable-bracketed-paste onSa kasamaang-palad, ipinapakita rin ng site ng pagsubok ng Horn kung paano i-bypass ang proteksyong ito sa pamamagitan ng mismong pag-format ng text at nauuwi sa maagang paglalapat ng Bracketed mode dito. Gumagana ito dahil hindi wastong na-filter ng ilang mga terminal ang mga pagkakasunud-sunod ng pagtakas bago idagdag ang sarili nila. Halimbawa, sa akin ay hindi ko nagawang matagumpay na makumpleto ang mga pagsubok sa Konsole kahit na may tamang pagsasaayos .inputrc file. Nangangahulugan ito na madali mong ma-corrupt ang configuration ng iyong system dahil sa isang hindi sinusuportahang application o isang hindi wastong na-configure na shell. Ito ay lalong mapanganib kapag nagla-log in sa mga malalayong server, kung saan ang maingat na pagsasaayos ng trabaho ay hindi gaanong karaniwan, lalo na kung marami kang ganoong malayuang makina.
Ang isang mahusay na solusyon sa problemang ito ay ang pag-paste ng pagkumpirma plugin para sa terminal urxvt, na humihingi lang ng pahintulot na magpasok ng anumang text na naglalaman ng mga bagong linya. Wala akong nakitang mas secure na opsyon para sa text attack na inilarawan ni Horn.
Mga tab at profile
Ang isang sikat na feature ngayon ay suporta para sa isang naka-tab na interface, na tutukuyin namin bilang isang terminal window na naglalaman ng ilang higit pang mga terminal. Ang function na ito ay naiiba para sa iba't ibang mga terminal, at bagama't ang mga tradisyunal na xterm terminal ay hindi sumusuporta sa mga tab sa lahat, mas modernong terminal incarnation tulad ng Xfce Terminal, GNOME Terminal at Konsole ay may ganitong function. Sinusuportahan din ng Urxvt ang mga tab, ngunit kung gumagamit ka ng isang plugin. Ngunit sa mga tuntunin ng suporta sa tab mismo, ang Terminator ay ang hindi mapag-aalinlanganang pinuno: hindi lamang nito sinusuportahan ang mga tab, ngunit maaari ring ayusin ang mga terminal sa anumang pagkakasunud-sunod (tingnan ang larawan sa ibaba).
Ang isa pang tampok ng Terminator ay ang kakayahang "i-grupo" ang mga tab na ito nang magkasama at ipadala ang parehong mga keystroke sa maraming terminal nang sabay-sabay, na nagbibigay ng magaspang na tool para sa pagsasagawa ng maramihang operasyon sa maraming server nang sabay-sabay. Ang isang katulad na tampok ay ipinatupad din sa Konsole. Para magamit ang feature na ito sa ibang mga terminal, dapat kang gumamit ng third party software gaya ng , o .
Lalo na gumagana ang mga tab kapag ipinares sa mga profile: halimbawa, maaari kang magkaroon ng isang tab para sa email, isa pa para sa chat, at iba pa. Ito ay mahusay na suportado ng Konsole Terminal at GNOME Terminal. Parehong pinapayagan ang bawat tab na awtomatikong ilunsad ang sarili nitong profile. Sinusuportahan din ng Terminator ang mga profile, ngunit hindi ako makahanap ng paraan upang awtomatikong maglunsad ng ilang program kapag nagbukas ka ng isang partikular na tab. Ang ibang mga terminal ay walang konsepto ng "profile" sa lahat.
Ruffles
Ang huling bagay na tatalakayin ko sa unang bahagi ng artikulong ito ay ang hitsura ng mga terminal. Halimbawa, ang GNOME, Xfce at urxvt ay sumusuporta sa transparency, ngunit kamakailan ay nag-drop ng suporta para sa mga larawan sa background, na pinipilit ang ilang mga user na lumipat sa terminal. . Personally, masaya ako dito at simple lang Mga mapagkukunan ng Xres, na nagtatakda ng base set ng mga kulay ng background para sa urxvt. Gayunpaman, ang hindi karaniwang mga tema ng kulay ay maaari ding lumikha ng mga problema. Halimbawa, kasama ang mga aplikasyon и , dahil gumagamit na sila ng sarili nilang kulay.
ay hindi sumusuporta sa mga kulay, at ang mga bago ay kadalasang limitado sa isang 256-kulay na palette. Para sa mga advanced na user na nag-istilo ng kanilang mga terminal, ang mga shell prompt o status bar sa mga kumplikadong paraan ay maaaring maging isang nakakainis na limitasyon. sinusubaybayan kung aling mga terminal ang may suportang "True Color". Kinukumpirma ng aking mga pagsusuri na ang st, Alacritty at VTE-based na mga terminal ay perpektong sumusuporta sa True Color. Ang ibang mga terminal ay hindi masyadong maganda sa bagay na ito at, sa katunayan, hindi man lang nagpapakita ng 256 na kulay. Sa ibaba makikita mo ang pagkakaiba sa pagitan ng suporta ng True Color sa mga terminal ng GNOME, st at xterm, na mahusay na gumagana nito sa kanilang 256 color palette, at urxvt, na hindi lamang nabigo sa pagsubok, ngunit nagpapakita pa ng ilang kumikislap na mga character sa halip na sila.
Sinusuri din ng ilang terminal ang teksto para sa mga pattern ng URL upang gawing naki-click ang mga link. Nalalapat ito sa lahat ng terminal na nagmula sa VTE, habang ang urxvt ay nangangailangan ng isang espesyal na plugin na magpapabago ng mga URL sa isang pag-click o gamit ang isang keyboard shortcut. Iba pang mga terminal na sinubukan ko ang mga display URL sa ibang mga paraan.
Sa wakas, ang isang bagong trend sa mga terminal ay ang opsyonalidad ng scroll buffer. Halimbawa, ang st ay walang scroll buffer; ipinapalagay na gagamit ang user ng terminal multiplexer tulad ng tmux at .
Ang Alacritty ay kulang din sa mga backscroll buffer, ngunit suporta nito dahil sa "malawak na feedback" sa paksang ito mula sa mga user. Bukod sa mga upstart na ito, bawat terminal na nasubukan ko na mahahanap ko ay sumusuporta sa reverse scrolling.
Subtotals
Sa ikalawang bahagi ng materyal (sa orihinal ang mga ito ay dalawang magkaibang mga artikulo - tantiya. lane) ihahambing namin ang pagganap, paggamit ng memorya at latency. Ngunit nakikita na natin na ang ilan sa mga terminal na pinag-uusapan ay may malubhang pagkukulang. Halimbawa, maaaring gusto ng mga user na regular na nagtatrabaho sa mga RTL script na isaalang-alang ang mlterm at pterm, dahil mas mahusay sila sa paghawak ng mga katulad na gawain kaysa sa iba. Maganda rin ang performance ng Konsole. Ang mga user na hindi gumagana sa mga RTL script ay maaaring pumili ng ibang bagay.
Sa mga tuntunin ng proteksyon laban sa malisyosong paglalagay ng code, ang urxvt ay namumukod-tangi dahil sa espesyal na pagpapatupad nito ng proteksyon laban sa ganitong uri ng pag-atake, na tila maginhawa para sa akin. Para sa mga naghahanap ng ilang mga kampana at sipol, ang Konsole ay sulit na tingnan. Sa wakas, nararapat na tandaan na ang VTE ay isang mahusay na base para sa mga terminal, na ginagarantiyahan ang suporta sa kulay, pagkilala sa URL, at iba pa. Sa unang tingin, ang default na terminal na kasama ng iyong paboritong kapaligiran ay maaaring matugunan ang lahat ng mga kinakailangan, ngunit hayaan nating bukas ang tanong na ito hanggang sa maunawaan natin ang pagganap.
Ituloy natin ang usapan
Sa pangkalahatan, ang pagganap ng mga terminal sa sarili nito ay maaaring mukhang isang napakalaking problema, ngunit sa paglabas nito, ang ilan sa mga ito ay nagpapakita ng nakakagulat na mataas na latency para sa software ng ganoong pangunahing uri. Susunod din ay titingnan natin kung ano ang tradisyonal na tinatawag na "bilis" (sa katunayan, ito ang bilis ng pag-scroll) at pagkonsumo ng memorya ng terminal (na may caveat na ito ay hindi kasing kritikal ngayon tulad ng mga dekada na ang nakalipas).
Pag-antala
Matapos ang isang masusing pag-aaral ng pagganap ng terminal, napagpasyahan ko na ang pinakamahalagang parameter sa bagay na ito ay ang latency (ping). Sa kanyang artikulo Tiningnan ni Pavel Fatin ang latency ng iba't ibang text editor at ipinahiwatig na ang mga terminal sa bagay na ito ay maaaring mas mabagal kaysa sa pinakamabilis na text editor. Ito ang pahiwatig na sa huli ay humantong sa akin sa pagpapatakbo ng sarili kong mga pagsubok at pagsulat ng artikulong ito.
Ngunit ano ang latency, at bakit ito napakahalaga? Sa kanyang artikulo, tinukoy ito ni Fatin bilang "ang pagkaantala sa pagitan ng pagpindot sa isang key at ang kaukulang pag-update ng screen" at sinipi , na nagsasabing: "Ang pagkaantala sa visual na feedback sa isang display ng computer ay may mahalagang epekto sa gawi at kasiyahan ng typist."
Ipinaliwanag ni Fatin na ang ping na ito ay may mas malalim na mga kahihinatnan kaysa sa kasiyahan lamang: "nagiging mas mabagal ang pag-type, mas maraming error ang nangyayari, at ang tensyon ng mata at kalamnan ay tumataas." Sa madaling salita, ang isang malaking pagkaantala ay maaaring humantong sa mga typo at mas mababang kalidad ng code, dahil ito ay humahantong sa karagdagang cognitive load sa utak. Ngunit ang mas masahol pa ay ang ping ay "nagdaragdag ng pagkapagod ng mata at kalamnan," na tila nagpapahiwatig sa hinaharap (Tila, ang ibig sabihin ng may-akda ay mga problema sa mga kalamnan ng mata, likod, braso at, siyempre, paningin - humigit-kumulang. lane) dahil sa paulit-ulit na stress.
Ang ilan sa mga epektong ito ay kilala sa mahabang panahon, at ang mga resulta , na inilathala noong 1976 sa journal na Ergonomics, ay nagsabi na ang pagkaantala ng 100 millisecond ay "makabuluhang nakakapinsala sa bilis ng pag-type." Kamakailan lamang, ipinakilala ang GNOME User Guide sa 10 millisecond, at kung lalayo ka pa, pagkatapos nagpapakita na ang 1 millisecond ay perpekto.
Isinagawa ni Fatin ang kanyang mga pagsusulit sa mga text editor; gumawa siya ng portable instrument na tinatawag , na ginamit ko upang subukan ang ping sa mga terminal emulator. Tandaan na ang pagsubok ay isinagawa sa simulation mode: sa katotohanan, kailangan nating isaalang-alang ang parehong input (keyboard, USB controller, atbp.) at output (video card buffer, monitor) latency. Ayon kay Fatin, sa karaniwang mga pagsasaayos ay humigit-kumulang 20 ms. Kung mayroon kang kagamitan sa paglalaro, maaari mong makuha ang figure na ito sa loob lamang ng 3 millisecond. Dahil mayroon na kaming napakabilis na hardware, hindi na kailangang magdagdag ng sarili nitong latency ang application. Ang layunin ni Fatin ay dalhin ang latency ng application sa 1 millisecond, o kahit na makamit ang pagdayal nang wala , paano pumasok .
Narito ang mga resulta ng aking mga sukat, pati na rin ang ilan sa mga resulta ni Fatin, upang ipakita na ang aking eksperimento ay sumasang-ayon sa kanyang mga pagsubok:
Ang unang bagay na tumama sa akin ay ang mas mahusay na oras ng pagtugon ng mas lumang mga programa tulad ng xterm at mlterm. Sa pinakamasamang latency ng rehistro (2,4 ms), gumanap sila nang mas mahusay kaysa sa pinakamabilis na modernong terminal (10,6 ms para sa st). Walang modernong terminal ang mas mababa sa 10 millisecond threshold. Sa partikular, nabigo ang Alacritty na matugunan ang claim na "pinakamabilis na terminal emulator na available", bagama't bumuti ang mga marka nito mula noong unang pagsusuri nito noong 2017. Sa katunayan, ang mga may-akda ng proyekto at nagsusumikap upang mapabuti ang display. Dapat ding tandaan na ang Vim gamit ang GTK3 ay isang order ng magnitude na mas mabagal kaysa sa katapat nitong GTK2. Mula dito maaari nating tapusin na ang GTK3 ay lumilikha ng karagdagang latency, at ito ay makikita sa lahat ng iba pang mga terminal na gumagamit nito (Terminator, Xfce4 Terminal at GNOME Terminal).
Gayunpaman, ang mga pagkakaiba ay maaaring hindi kapansin-pansin sa mata. Tulad ng ipinaliwanag ni Fatin, "hindi mo kailangang malaman ang pagkaantala para magkaroon ito ng epekto sa iyo." Nagbabala rin si Fatin tungkol sa karaniwang paglihis: "anumang mga abala sa latency (jitter) ay lumikha ng karagdagang stress dahil sa kanilang hindi mahuhulaan."
Ang graph sa itaas ay kinuha sa purong Debian 9 (stretch) na may . Ang kapaligirang ito ay gumagawa ng pinakamahusay na mga resulta sa mga pagsubok sa latency. Sa lumalabas, ang GNOME ay lumilikha ng karagdagang ping na 20 ms para sa lahat ng mga sukat. Ang isang posibleng paliwanag para dito ay ang pagkakaroon ng mga programa na may kasabay na pagproseso ng mga kaganapan sa pag-input. Si Fatin ay nagbibigay ng isang halimbawa para sa naturang kaso , na nagdaragdag ng pagkaantala sa pamamagitan ng pagproseso ng lahat ng mga kaganapan sa pag-input nang sabay-sabay. Bilang default, ang GNOME ay mayroon ding window manager , na lumilikha ng karagdagang layer ng buffering, na nakakaapekto sa ping at nagdaragdag ng hindi bababa sa 8 milliseconds ng latency.
Bilis ng scroll
Ang susunod na pagsubok ay isang tradisyunal na "bilis" o "bandwidth" na pagsubok, na sumusukat kung gaano kabilis makakapag-scroll ang terminal sa isang pahina habang nagpapakita ng maraming teksto sa screen. Iba-iba ang mekanika ng pagsusulit; ang orihinal na pagsubok ay para lang makabuo ng parehong text string gamit ang seq command. Kasama sa iba pang mga pagsubok ang pagsusulit ni Thomas E. Dickey (xterm maintainer), na paulit-ulit . Sa isa pang pagsusuri ng pagganap ng terminal gumagamit ng base32 na naka-encode na string ng mga random na byte, na output sa terminal gamit ang cat. Itinuturing ni Luu na ang naturang pagsubok ay "bilang walang silbi na benchmark gaya ng maiisip ng isa" at sa halip ay nagmumungkahi ng paggamit ng terminal na tugon bilang pangunahing sukatan. Tinatawag din ni Dickey ang kanyang pagsubok na nakaliligaw. Gayunpaman, kinikilala ng parehong may-akda na maaaring maging isyu ang terminal window bandwidth. Natuklasan ni Luu ang pagyeyelo ng Emacs Eshell noong nagpapakita ng malalaking file, at in-optimize ni Dickey ang terminal para maalis ang katamlan ng visual ng xtrerm. Kaya't mayroon pa ring ilang merito sa pagsubok na ito, ngunit dahil ang proseso ng pag-render ay ibang-iba mula sa terminal patungo sa terminal, maaari rin itong gamitin bilang bahagi ng pagsubok upang subukan ang iba pang mga parameter.
Dito makikita natin ang rxvt at st pull sa unahan ng kumpetisyon, na sinusundan ng mas bagong Alacritty, na idinisenyo na may pagtuon sa pagganap. Susunod ay ang Xfce (pamilya ng VTE) at Konsole, na halos dalawang beses nang mas mabilis. Ang huli ay xterm, na limang beses na mas mabagal kaysa sa rxvt. Sa panahon ng pagsubok, ang xterm ay nag-ripple din nang malaki, na ginagawang mahirap makita ang pagpasa ng teksto kahit na ito ay ang parehong linya. Ang Konsole ay mabilis, ngunit ito ay nakakalito minsan: ang display ay magye-freeze paminsan-minsan, nagpapakita ng bahagyang text o hindi ito ipinapakita. Ang ibang mga terminal ay malinaw na nagpakita ng mga string, kabilang ang st, Alacritty, at rxvt.
Ipinaliwanag ni Dickey na ang mga pagkakaiba sa pagganap ay dahil sa disenyo ng mga scroll buffer sa iba't ibang mga terminal. Sa partikular, inaakusahan niya ang rxvt at iba pang mga terminal ng "hindi pagsunod sa mga pangkalahatang tuntunin":
"Hindi tulad ng xterm, hindi sinubukan ng rxvt na ipakita ang lahat ng mga update. Kung mahuhuli ito, tatanggihan nito ang ilang mga update upang abutin. Mas malaki ang epekto nito sa maliwanag na bilis ng pag-scroll kaysa sa organisasyon ng panloob na memorya. Ang isang disbentaha ay ang ASCII animation ay medyo hindi tumpak."
Upang ayusin ang pinaghihinalaang xterm sluggishness, iminumungkahi ni Dickey ang paggamit ng mapagkukunan , na nagpapahintulot sa xterm na itapon ang ilang mga update sa screen upang makasabay sa daloy. Kinumpirma ng aking mga pagsusuri na ang fastScroll ay nagpapabuti sa pagganap at nagdudulot ng xterm sa par sa rxvt. Ito ay, gayunpaman, isang medyo magaspang na saklay, gaya ng ipinaliwanag mismo ni Dickey: "kung minsan ang xterm - tulad ng konsole - ay tila humihinto habang naghihintay ng isang bagong hanay ng mga pag-update sa screen pagkatapos na maalis ang ilan." Sa puntong ito, tila natagpuan ng ibang mga terminal ang pinakamahusay na kompromiso sa pagitan ng bilis at integridad ng pagpapakita.
Pagkonsumo ng mapagkukunan
Hindi alintana kung makatuwirang isaalang-alang ang bilis ng pag-scroll bilang sukatan ng pagganap, binibigyang-daan kami ng pagsubok na ito na gayahin ang pag-load sa mga terminal, na nagbibigay-daan naman sa amin na sukatin ang iba pang mga parameter gaya ng memorya o paggamit ng disk. Nakuha ang mga sukatan sa pamamagitan ng pagpapatakbo ng tinukoy na pagsubok seq sa ilalim ng pagsubaybay sa proseso ng Python. Kinokolekta niya ang data ng metro para sa ru_maxrss, dami ru_oublock и ru_inblock at isang simpleng timer.
Sa pagsusulit na ito, ang ST ay tumatagal ng unang lugar na may pinakamababang average na pagkonsumo ng memorya na 8 MB, na hindi nakakagulat na isinasaalang-alang na ang pangunahing ideya ng disenyo ay pagiging simple. Ang mlterm, xterm at rxvt ay kumonsumo ng kaunti pa - mga 12 MB. Ang isa pang kapansin-pansing resulta ay ang Alacritty, na nangangailangan ng 30 MB upang tumakbo. Pagkatapos ay mayroong mga terminal ng pamilyang VTE na may mga numero mula 40 hanggang 60 MB, na medyo marami. Ang pagkonsumo na ito ay maaaring ipaliwanag sa pamamagitan ng katotohanan na ang mga terminal na ito ay gumagamit ng mas mataas na antas ng mga aklatan, halimbawa, GTK. Huli ang Konsole na may napakalaking 65MB na pagkonsumo ng memory sa panahon ng mga pagsubok, bagama't maaari itong bigyang-katwiran sa pamamagitan ng napakalawak nitong hanay ng mga feature.
Kung ikukumpara sa mga nakaraang resulta na nakuha sampung taon na ang nakalilipas, ang lahat ng mga programa ay nagsimulang kumonsumo ng higit na memorya. Ang Xterm ay nangangailangan noon ng 4 MB, ngunit ngayon ay nangangailangan ito ng 15 MB sa pagsisimula pa lamang. Mayroong katulad na pagtaas sa pagkonsumo para sa rxvt, na ngayon ay nangangailangan ng 16 MB sa labas ng kahon. Ang Xfce Terminal ay tumatagal ng 34 MB, na tatlong beses na mas malaki kaysa dati, ngunit ang GNOME Terminal ay nangangailangan lamang ng 20 MB. Siyempre, ang lahat ng mga nakaraang pagsubok ay isinagawa sa 32-bit na arkitektura. Sa LCA 2012 Rusty Russell , na mayroong maraming mas banayad na mga kadahilanan na maaaring ipaliwanag ang pagtaas sa pagkonsumo ng memorya. Sa pagsasabi niyan, nabubuhay tayo ngayon sa panahon kung saan mayroon tayong mga gigabytes ng memorya, kaya't mapapamahalaan natin kahit papaano.
Gayunpaman, hindi ko maiwasang madama na ang paglalaan ng mas maraming memorya sa isang bagay na kasing-halaga ng terminal ay isang pag-aaksaya ng mga mapagkukunan. Ang mga programang ito ay dapat na ang pinakamaliit sa pinakamaliit, ay dapat tumakbo sa anumang "kahon", kahit na isang kahon ng sapatos, kung sakaling dumating tayo sa punto kung saan kailangan nilang magkaroon ng mga sistema ng Linux (at alam mo na ito ay magiging gayon. ). Ngunit sa mga numerong ito, ang paggamit ng memorya ay magiging isyu sa hinaharap sa anumang kapaligiran na nagpapatakbo ng maraming terminal maliban sa ilan sa pinakamagaan at pinakalimitado sa mga kakayahan. Upang mabayaran ito, ang GNOME Terminal, Konsole, urxvt, Terminator at Xfce Terminal ay mayroong Daemon mode na nagbibigay-daan sa iyong kontrolin ang maramihang mga terminal sa pamamagitan ng isang proseso, na nililimitahan ang kanilang paggamit ng memorya.
Sa panahon ng aking mga pagsubok, nakarating ako sa isa pang hindi inaasahang resulta tungkol sa disk read-write: Inaasahan kong wala akong makita dito, ngunit lumabas na ang ilang mga terminal ay nagsusulat ng pinakamaraming data sa disk. Kaya, ang VTE library ay talagang nagpapanatili ng isang scroll buffer sa disk (ang tampok na ito , at ito ay nangyayari pa rin). Ngunit hindi tulad ng mas lumang mga pagpapatupad, ngayon ay hindi bababa sa ang data na ito ay naka-encrypt gamit ang AES256 GCM (). Ngunit lumitaw ang isang makatwirang tanong: ano ang napakaespesyal sa VTE library na nangangailangan ito ng hindi pamantayang diskarte sa pagpapatupad...
Konklusyon
Sa unang bahagi ng artikulo, nalaman namin na ang mga terminal na nakabatay sa VTE ay may magandang hanay ng mga tampok, ngunit ngayon ay nakita namin na ito ay kasama ng ilang mga gastos sa pagganap. Ngayon ang memorya ay hindi isang isyu dahil ang lahat ng mga terminal ng VTE ay maaaring kontrolin sa pamamagitan ng isang proseso ng Daemon, na naglilimita sa kanilang gana. Gayunpaman, ang mga mas lumang system na may pisikal na limitasyon sa dami ng RAM at mga kernel buffer ay maaaring mangailangan pa rin ng mga naunang bersyon ng mga terminal, dahil mas kaunting mapagkukunan ang ginagamit nila. Bagama't mahusay ang pagganap ng mga terminal ng VTE sa mga pagsubok sa throughput (pag-scroll), ang kanilang display latency ay nasa itaas ng threshold na itinakda sa GNOME User Guide. Malamang na dapat itong isaalang-alang ng mga developer ng VTE. Kung isasaalang-alang natin na kahit para sa mga baguhan na gumagamit ng Linux na nakakaharap ng isang terminal ay hindi maiiwasan, maaari nilang gawin itong mas madaling gamitin. Para sa mga bihasang geeks, ang paglipat mula sa default na terminal ay maaaring mangahulugan ng mas kaunting stress sa mata at ang kakayahang maiwasan ang mga pinsala at sakit na nauugnay sa trabaho sa hinaharap dahil sa mahabang sesyon ng trabaho. Sa kasamaang-palad, ang lumang xterm at mlterm lang ang nagdadala sa amin sa magic ping threshold na 10 milliseconds, na hindi katanggap-tanggap para sa marami.
Ipinakita rin ng mga sukat ng benchmark na dahil sa pagbuo ng mga graphical na kapaligiran ng Linux, ang mga developer ay kailangang gumawa ng ilang mga kompromiso. Maaaring gusto ng ilang user na tumingin sa mga regular na window manager habang nagbibigay sila ng makabuluhang pagbawas ng ping. Sa kasamaang palad, hindi posible na sukatin ang latency para sa Wayland: ang Typometer program na ginamit ko ay nilikha para sa kung ano ang idinisenyo ng Wayland upang maiwasan: pag-espiya sa ibang mga bintana. Umaasa ako na ang Wayland compositing ay gumaganap nang mas mahusay kaysa sa X.org, at umaasa din ako na sa hinaharap ay may makakahanap ng paraan upang sukatin ang latency sa kapaligirang ito.
Pinagmulan: www.habr.com