Terminal: Mengetik di dalam terminal WSL default terasa luar biasa, mengapa itu lebih baik daripada setiap aplikasi lain?

Saya benar-benar tidak keberatan ketika seseorang datang dan memutuskan untuk memberi tahu kami bahwa kami melakukan sesuatu dengan baik. Kami mendengar begitu banyak keluhan setiap hari sehingga postingan seperti ini menghirup udara segar. Terima kasih atas ucapan terima kasih Anda!

Juga, saya dengan senang hati mendiskusikan hal ini dengan Anda sampai Anda benar-benar muak membacanya. Silakan tanyakan tindak lanjut yang Anda inginkan. Saya senang mengobrol tentang pekerjaan saya. : P

Jika saya harus menebak secara terpelajar tentang apa yang membuat kami lebih cepat daripada hampir semua aplikasi lain di Windows dalam meletakkan teks Anda di layar ... Saya akan mengatakan itu karena secara harfiah itulah satu-satunya tugas kami! Juga mungkin karena kita menggunakan API tingkat paling tua dan paling rendah yang dimiliki Windows untuk menyelesaikan pekerjaan ini.

Hampir semua hal lain yang Anda cantumkan memiliki semacam lapisan atau kerangka kerja yang terlibat, atau banyak, banyak lapisan dan kerangka kerja, ketika Anda mulai berbicara tentang Elektron dan Javascript. Kami tidak.

Kami memiliki satu jendela telanjang, super tidak khusus tanpa kontrol tambahan yang menyertainya. Kami mendapatkan kunci kami dimasukkan ke dalam kami dari tepat di atas kernel karena kami memprosesnya dari pesan jendela dan bukan dari semacam kerangka eventing yang umum untuk hampir semua kerangka kerja UI yang lebih rumit daripada kami (WPF, WinForms, UWP, Elektron). Dan kami membuang teks kami langsung ke permukaan jendela menggunakan PolyTextOut GDI tanpa embel-embel.

Bahkan notepad.exe memiliki beberapa kontrol paling sedikit di jendelanya dan mungkin (saya belum melihat) menggunakan semacam kerangka perpustakaan dalam kontrol edit untuk mengetahui tata letak teksnya (yang mungkin menggunakan perpustakaan lain kerangka kerja untuk dukungan internasionalisasi ...)

Tentu saja ini juga berarti kita memiliki trade off. Kami tidak mendukung teks internasional sepenuhnya seperti hampir semua aplikasi lainnya. RTL? Tidak ada zona go sekarang. Pasangan pengganti dan emoji? Kami menuju ke sana tapi belum sampai di sana. Skrip Indic? Nggak.

Kenapa kita seperti ini? Untuk satu, conhost.exe sudah tua sebagai kotoran. Itu harus menggunakan lapisan bawah logam telanjang dari segala sesuatu karena itu dibuat sebelum sebagian besar kerangka lainnya dibuat. Dan juga mempertahankan level serendah mungkin karena ini adalah hal pertama yang perlu dikemukakan saat membawa edisi atau perangkat sistem operasi baru sebelum Anda memiliki semua hal bagus seperti kerangka kerja atau apa yang diperlukan kerangka itu. beroperasi. Juga ditulis dalam C / C ++ yang kira-kira serendah dan logam kosong yang bisa kita dapatkan.

Akankah peningkatan UI ini datang ke aplikasi lain di Windows? Hampir pasti tidak. Mereka melakukan terlalu banyak hal yang merupakan hal baik dan buruk. Saya iri dengan kemampuan mereka untuk hanya memanggil satu metode dan tata letak teks dengan cara yang tidak rumit dalam bahasa apa pun tanpa menghitung piksel secara manual atau peduli tentang gaya apa yang berlaku untuk font mereka. Tapi perhitungan piksel manual saya, matematika wilayah kotor, kegilaan wilayah gulir, dan banyak lagi membuatnya jadi kami lebih cepat dari mereka. Saya juga iri bahwa ketika seseorang mengatakan "hei, bisakah Anda menambahkan bilah status ke bagian bawah jendela Anda" sehingga mereka dapat mengeklik dan menyeretnya ke tempatnya dengan Kerangka UI mereka dan itu hanya akan berfungsi di mana bagi kami, itu menjadi item backlog selamanya dan membuat saya mulas untuk memikirkan penerapan.

Akankah kita mencoba untuk mencegah kemunduran? Iya! Sekarang ini semacam proses manual. Kami mengidentifikasi bahwa ada sesuatu yang lambat dan kemudian kami mengeluarkan WPR dan mulai mengambil jejak. Kami menatap jalan panas dan mencoba mencari tahu apa yang sedang terjadi dan kemudian memperbaikinya. Misalnya, dalam satu atau dua siklus terakhir, kami berfokus pada alokasi heap sebagai area utama tempat kami dapat meningkatkan kinerja ujung-ke-ujung, mengubah banyak kode kami untuk menggunakan fasad seperti iterator yang dibuat berdasarkan tumpukan atas permintaan yang mendasarinya. buffer alih-alih menerjemahkan dan mengalokasikannya ke dalam ruang heap baru untuk setiap tingkat pemrosesan.

Selain itu, @bitcrazed ingin kami mengotomatiskan pengujian kinerja dengan cara khusus conhost, tetapi saya belum menemukan lingkungan yang terkontrol untuk melakukan ini. Sistem Rekayasa Windows menjalankan tes kinerja setiap malam yang memberi kami cara kasar untuk mengetahui apakah kami mengacaukan sesuatu untuk seluruh sistem operasi, dan mereka secara teknis menawarkan cara yang sangat baik bagi kami untuk memasukkan tes kinerja kami sendiri ... tapi saya hanya belum sempat melakukannya. Jika Anda memiliki ide tentang cara kami melakukan ini secara otomatis, saya mendengarkan.

Jika ada hal lain yang ingin Anda ketahui, beri tahu saya. Saya bisa terus sepanjang hari. Saya menghapus seperti 15 garis singgung dari balasan ini sebelum mempostingnya ....

Berbicara tentang Windows API tingkat rendah, saya menemukan bahwa setiap _user mode_ komponen kedua Konsol (conhost.exe, cmd.exe ...) dan WSL (wsl.exe, LxssManager.dll ...) menggunakan C ++ _STL_ sangat banyak. Misalnya, dalam manipulasi string, alokasi memori, tabel virtual, dll. Apakah akan ada peningkatan performa jika hanya C yang digunakan?

Saya tidak akan menganggap mereka menggunakan C ++ STL "sangat". Mereka pasti menggunakan beberapa koleksi dan mungkin sedikit manipulasi string dan algoritme di sana-sini. Saya merasa ada lebih banyak hal untuk STL daripada beberapa bit itu.

Tapi bagaimanapun ... sebagian besar hal yang Anda gambarkan ditulis langsung di C beberapa waktu yang lalu. Kami telah secara selektif menggunakan C ++ dan STL di semakin banyak dari mereka sebagai tradeoff sadar. Selama kami benar-benar mengetahui apa yang dilakukan template di balik terpal dan menggunakan yang benar dengan hati-hati, kami biasanya hanya memperdagangkan sejumlah kecil kinerja sambil mendapatkan sejumlah besar keamanan dan kemudahan pemrograman.

Keamanan sebenarnya adalah alasan utama mengapa kami menggunakan templat STL daripada mencoba membuat struktur kami sendiri bila memungkinkan. Menggunakan template STL untuk koleksi dan string umumnya memberi kami pemeriksaan batas yang seharusnya dilakukan secara manual dengan cara yang rawan kesalahan (atau tidak dilakukan sama sekali!)

Juga saya tidak terlalu yakin bahwa memiliki 17 antrian berbeda dan implementasi daftar tertaut di dalam kode konsol ketika lurus C secara keseluruhan lebih baik untuk kinerja daripada menggunakan std :: queue dan std :: list hari ini. Ini mungkin menghabiskan lebih banyak ruang pada disk untuk setiap implementasi individu yang merupakan jenis masalah kinerja yang berbeda (penyimpanan dan I / O pemuatan halaman).

Terima kasih banyak telah meluangkan waktu untuk menulis balasan itu, dan tidak ada masalah dengan pujiannya.

Selama beberapa bulan terakhir saya mencari pengaturan terminal yang bagus, dan menurut saya ubuntu.exe dengan tmux mendekati kesempurnaan yang bisa Anda dapatkan dengan alat yang kami miliki saat ini. Terminal ubuntu.exe itu sendiri sangat cepat dan tmux memberi Anda semua barang yang memenuhi syarat untuk hidup (tab, panel terpisah, pencarian buffer, dll.).

Benar-benar menantikan rilis mendatang yang membuat tema warna lebih kompatibel dan penyempurnaan terkait properti seperti tombol pintas untuk memperbesar +/- pada ukuran font.

@miniksa : Terima kasih untuk postingan yang sangat menarik!

kami menggunakan API tingkat paling tua dan paling rendah yang dimiliki Windows untuk menyelesaikan pekerjaan ini.

Saya sudah lama penasaran tentang ini. Anda tampaknya mengacu pada berbagai API Win32 (USER32 / GDI32). Akhir-akhir ini saya menjadi tidak yakin apakah levelnya masih serendah yang bisa didapatkan di versi Windows terbaru (8.0 dan yang lebih baru), atau apakah API ini telah diubah secara diam-diam untuk menggantikan hal-hal lain (seperti Direct2D, DirectWrite, dll.). Bagaimana API lama berhubungan dengan yang lebih baru? Saya akan senang jika Anda bisa menjelaskan sedikit itu!

@ stakx , saya mengacu pada USER32 dan GDI32.

Saya akan memberi Anda gambaran sepintas tentang apa yang saya tahu di luar kepala saya tanpa menghabiskan berjam-jam untuk mengkonfirmasi detailnya. Karena itu, beberapa di antaranya mungkin bisa dilambaikan dengan tangan dan bisa jadi agak salah tetapi mungkin ke arah yang benar. Anggap setiap pernyataan sebagai pengetahuan pribadi saya tentang cara kerja dunia dan tunduk pada opini atau kesalahan.

Untuk grafis bagian pipeline (GDI32), bagian mode pengguna GDI cukup jauh di bawah. Aplikasi memanggil GDI32, beberapa pekerjaan dilakukan di DLL itu di sisi mode pengguna, kemudian panggilan kernel melompat ke kernel dan menggambar terjadi.

Bagian yang Anda pikirkan tentang "secara diam-diam dikonversi untuk duduk di atas hal-hal lain" mungkin adalah bahwa begitu kita menekan panggilan kernel, sekelompok barang GDI kernel cenderung ditempatkan ulang di atas barang yang sama seperti DirectX saat itu benar-benar ditangani oleh NVIDIA / AMD / Intel / dll. driver grafis dan GPU di bagian bawah tumpukan. Saya pikir ini terjadi dengan arsitektur ulang driver grafis yang datang sebagai bagian dari WDDM untuk Windows Vista. Ada dokumen di luar sana tentang panggilan apa yang masih sangat cepat di GDI dan mana yang lebih lambat sebagai akibat dari peron platform ulang. Terakhir kali saya menemukan dokumen itu dan memeriksanya, kami menggunakan yang cepat.

Di atas GDI, saya percaya ada hal-hal seperti Common Controls atau comctl32.dll yang menyediakan orang-orang sekumpulan tombol dan elemen yang dapat digunakan kembali untuk membuat UI mereka sebelum kami memiliki kerangka kerja deklaratif yang lebih baik. Kami tidak benar-benar menggunakannya di konsol (kecuali di lembar properti dari menu klik kanan).

Adapun DirectWrite dan D2D dan D3D dan DXGI itu sendiri, mereka adalah sekumpulan perintah dan jalur terpisah yang benar-benar terpisah dari GDI sama sekali baik dalam mode pengguna maupun kernel. Mereka tidak benar-benar terkait selain itu ada beberapa ketentuan interoperabilitas di antara keduanya. Sebagian besar kerangka UI kami yang lain cenderung dibangun di atas tumpukan DirectX. XAML pasti. Saya pikir WPF adalah. Tidak yakin tentang WinForms. Dan saya yakin tumpukan komposisi dan pengelola jendela juga menggunakan DirectX.

Adapun bagian input / interaksi dari pipeline (USER32), saya cenderung menemukan sebagian besar hal baru lainnya (setidaknya untuk PC desktop) dibangun di atas apa yang sudah ada. Konsep utama USER32 adalah jendela dan pegangan jendela dan semuanya dikirim ke pegangan jendela. Selama Anda menggunakan mesin desktop (atau laptop atau apa pun ... Maksud saya, mesin bertenaga Windows bergaya klasik), ada pegangan jendela yang terlibat dan pesan-pesan yang beredar dan itu berarti kita sedang membicarakan USER32.

Antrian pesan jendela hanyalah FIFO langsung (lebih atau kurang) dari input apa pun yang terjadi relevan dengan jendela itu saat berada di latar depan + apa pun yang telah dikirim ke jendela oleh komponen lain dalam sistem.

Teknologi dan kerangka kerja yang lebih baru seperti XAML dan WPF dan WinForms cenderung menerima pesan dari antrian pesan jendela dengan satu atau lain cara dan memprosesnya dan mengubahnya menjadi event callback ke berbagai objek yang telah mereka sediakan dalam dunia mereka.

Namun, teknologi baru yang juga bekerja pada platform non-desktop lain seperti XAML cenderung memiliki kemampuan untuk memproses barang dari tumpukan non-USER32 yang sama sekali berbeda. Ada tumpukan paralel terpisah untuk USER32 dengan semua inovasi dan kesadaran baru kami tentang bagaimana masukan dan interaksi harus terjadi yang tidak secara tepat menangani antrean perpesanan klasik dan jendela menangani dengan cara yang sama. Ini adalah seluruh keluarga Core * hal-hal seperti CoreWindow dan CoreMessaging. Mereka juga memiliki konsep berbeda tentang "apa itu pengguna" yang tidak terlalu terpusat di sekitar pantat Anda di kursi bergulir di depan layar dengan keyboard dan mouse di atas meja.

Sekarang, jika Anda menggunakan XAML atau salah satu Framework lainnya ... semua kerumitan ini ditangani untuk Anda. XAML mengetahui cara menggambar di DirectX untuk Anda dan bernegosiasi dengan kompositor dan pengelola jendela untuk mendapatkan efek keren atas nama Anda. Ini menentukan apakah akan mendapatkan peristiwa input Anda dari USER32 atau Core * atau apa pun secara transparan tergantung pada platform Anda dan tumpukan masukan dapat menangani pena, sentuhan, keyboard, mouse, dan sebagainya secara terpadu. Ia memiliki ketentuan di dalamnya yang tertanam untuk melakukan segala macam globalisasi, aksesibilitas, interaksi input, dll. Hal-hal yang membuat hidup Anda mudah. Tetapi Anda dapat memilih untuk langsung pergi ke tingkat rendah dan menanganinya sendiri atau melewati menangani apa yang tidak Anda pedulikan.

Triknya adalah GDI32 dan USER32 dirancang untuk dunia terbatas dengan sekumpulan perintah terbatas. PC Desktop adalah satu-satunya hal yang ada, pengguna tunggal di keyboard dan mouse, output grafis sederhana ke monitor VGA. Jadi menggunakannya secara langsung pada "level rendah" seperti yang dilakukan oleh conhost sangatlah mudah. Platform baru dapat digunakan pada "tingkat rendah" tetapi urutan besarnya lebih rumit karena sekarang memperhitungkan semua yang telah terjadi dengan komputasi pribadi dalam 20+ tahun seperti faktor bentuk yang berbeda, beberapa pengguna aktif, beberapa adaptor grafik, dan seterusnya dan seterusnya. Jadi Anda cenderung menggunakan kerangka saat menggunakan barang baru agar kepala Anda tidak meledak. Mereka menanganinya untuk Anda, tetapi mereka menangani lebih dari yang pernah mereka lakukan sebelumnya sehingga mereka lebih lambat sampai taraf tertentu.

Jadi, apakah GDI32 dan USER32 "lebih rendah" dari yang baru? Semacam.
Bisakah Anda serendah itu dengan barang-barang baru? Sebagian besar ya, tetapi Anda mungkin tidak seharusnya dan tidak mau.
Apakah yang baru ditayangkan di atas yang lama atau yang lama diganti dengan yang baru? Terkadang dan / atau sebagian.
Pada dasarnya ... ini seperti jawaban untuk perangkat lunak apa pun ... "ini adalah bencana yang tidak tanggung-tanggung dan jika kita semua mundur sejenak, kita akan terkejut bahwa itu berfungsi sama sekali." : P

Bagaimanapun, itu cukup mengoceh untuk satu pagi. Semoga itu menjawab pertanyaan Anda dan memberi Anda sedikit lebih banyak wawasan.

Semoga itu menjawab pertanyaan Anda dan memberi Anda sedikit lebih banyak wawasan.

@miniksa , memang! Masuk akal juga. Terima kasih banyak telah meluangkan waktu untuk menulis semuanya! : +1:

Saya akan menutup masalah ini sekarang. Terima kasih atas pertanyaannya dan saya senang Anda menikmati informasinya.