Terminal: デフォルトのWSLターミナル内での入力は素晴らしいと感じますが、他のどのアプリよりも優れているのはなぜですか？

誰かが来て、私たちが何かで良い仕事をしていると私たちに言うことに決めたとき、私は本当に気にしません。 私たちは毎日非常に多くの苦情を聞いているので、このような投稿は新鮮な空気の息吹です。 ありがとうございます！

また、あなたがそれを読むことに完全にうんざりするまで、私はあなたとこれについて話し合うことを嬉しく思います。 ご希望のフォローアップはお問い合わせください。 私は自分の仕事について熱狂的に成長しています。 ：P

あなたのテキストを画面に表示する際に、Windows上の他のほとんどのアプリケーションよりも高速になっている理由について知識に基づいた推測をしなければならなかったとしたら...それは文字通り私たちの唯一の仕事だからです！ また、おそらく、Windowsがこの作業を実行するために必要な最も古くて最低レベルのAPIの近くでdarnを使用しているためです。

ElectronとJavascriptについて話し始めると、リストした他のほとんどすべてに、ある種のレイヤーまたはフレームワーク、あるいは多くのレイヤーとフレームワークが含まれます。 私たちはしません。

追加のコントロールが接続されていない、非常に特別でないウィンドウが1つあります。 キーは、ウィンドウメッセージから処理しているので、カーネルのすぐ上からフィードされます。キーは、他のより複雑なUIフレームワーク（WPF、WinForms、UWP、電子）。 そして、フリルなしでGDIのPolyTextOutを使用して、テキストをウィンドウの表面に直接ダンプします。

notepad.exeさえ、少なくともウィンドウに複数のコントロールがあり、おそらく（私は見ていませんが）編集コントロールで何らかのライブラリフレームワークを使用して、テキストレイアウトを把握しています（おそらく別のライブラリを使用しています）。国際化サポートのフレームワーク...）

もちろん、これはトレードオフがあることも意味します。 他のほとんどすべてのアプリケーションのように、完全に国際的なテキストはサポートしていません。 RTL？ 現在、ゴーゾーンはありません。 代理ペアと絵文字？ 私たちはそこに着きましたが、まだそこにはいません。 指標スクリプト？ いいえ。

なんでこんな感じなの？ 一つには、 conhost.exeは汚れとして古いです。 他のほとんどのフレームワークが作成される前に作成されたため、すべてのベアメタル最下層を使用する必要があります。 また、フレームワークやそれらのフレームワークに必要なものがすべて揃う前に、新しいオペレーティングシステムのエディションやデバイスを起動するときに最初に表示する必要があるのは、可能な限り低いレベル/ボトムレベルを維持するためです。動作します。 また、C / C ++で記述されており、可能な限り低く、ベアメタルです。

このUIの機能強化は、Windows上の他のアプリにも適用されますか？ ほぼ間違いなくそうではありません。 彼らはあまりにも多くのことが起こっており、それは良いことでも悪いことでもあります。 手動でピクセルを計算したり、フォントに適用されるスタイルを気にしたりせずに、1つのメソッドを呼び出して、テキストを複雑でない方法で任意の言語でレイアウトできることに嫉妬しています。 しかし、私の手動のピクセル計算、ダーティリージョンの計算、スクロールリージョンの狂気などにより、それらよりも高速になります。 また、誰かが「ウィンドウの下部にステータスバーを追加できますか」と言うと、UIフレームワークを使用してクリックしてドラッグできるので、私たちの場合はどこでも機能するので、うらやましいです。永遠にバックログアイテムであり、実装について考える胸焼けを与えてくれます。

それが後退しないようにしようとしますか？ はい！ 今のところ、それは一種の手動プロセスです。 何かが遅くなっていることを確認してから、 WPRを実行し、トレースを開始します。 私たちはホットパスを見つめ、何が起こっているのかを推論し、それを改善しようとします。 たとえば、最後の1、2サイクルでは、エンドツーエンドのパフォーマンスを向上させることができる主要な領域としてヒープ割り当てに焦点を当て、基になるリクエストに対してスタック構築されたイテレータのようなファサードを使用するようにコードを大量に変更しました処理の各レベルの新しいヒープスペースに変換して割り当てる代わりに、バッファ。

余談ですが、 @ bitcrazedは、コンホスト固有の方法でパフォーマンステストを自動化することを望んでいますが、これを実行するための制御された環境をまだ完全には理解していません。 Windowsエンジニアリングシステムは毎晩パフォーマンステストを実行し、オペレーティングシステム全体で何かを台無しにしたかどうかを大まかに知る方法を提供し、技術的には独自のパフォーマンステストを挿入するためのきめ細かい方法を提供します...しかし私はまだそれを回避していません。 自動化された方法でこれを行う方法についてのアイデアがあれば、私はすべての耳です。

他に知りたいことがあれば教えてください。 私は一日中行くことができました。 投稿する前に、この返信から15個の接線を削除しました。

低レベルのWindowsAPIと言えば、コンソール（conhost.exe、cmd.exe ...）とWSL（wsl.exe、LxssManager.dll ...）の両方のすべての_usermode_コンポーネントがC ++ _ STL_を大量に使用していることがわかりました。 たとえば、文字列操作、メモリ割り当て、仮想テーブルなどです。Cのみを使用した場合、パフォーマンスは向上しますか？

私はそれらがC ++ STLを「非常に」使用しているとは考えていません。 彼らは間違いなくいくつかのコレクションと、おそらく少しの文字列操作とアルゴリズムをあちこちで使用しています。 STLには、これらの数ビットよりもはるかに多くのものがあるように感じます。

しかしとにかく...あなたが説明することのほとんどは、しばらく前にCでまっすぐに書かれていました。 意識的なトレードオフとして、C ++とSTLを選択的に使用することが増えています。 テンプレートが内部で何をしているのかをよく理解し、正しいテンプレートを注意深く使用している限り、通常、セキュリティとプログラミングの容易さを大幅に向上させながら、ごくわずかなパフォーマンスしかトレードしていません。

実際、セキュリティは、可能な限り独自の構造を作成しようとするよりも、STLテンプレートを使用する大きな理由です。 コレクションと文字列にSTLテンプレートを使用すると、通常、エラーが発生しやすい方法で手動で実行する必要がある（またはまったく実行しない）境界チェックが可能になります。

また、ストレートCのときにコンソールコード内に17の異なるキューイングとリンクリストの実装がある方が、今日std :: queueとstd :: listを使用するよりも全体的にパフォーマンスが優れているかどうかは厳密にはわかりません。 おそらく、個々の実装ごとにより多くのディスク上のスペースを消費しましたが、これは異なるタイプのパフォーマンスの問題（ストレージとページロードI / O）です。

その返信を書くために時間を割いてくれてありがとう、そして賞賛に問題はありません。

過去数か月間、私は適切な端末のセットアップを探していました。tmuxを使用したubuntu.exeは、現在のツールを使用した場合と同じくらい完璧に近いと思います。 ubuntu.exe端末自体は非常に高速であり、tmuxはすべてのライフグッズ（タブ、分割ペイン、バッファー検索など）を提供します。

カラーテーマの互換性を高め、フォントサイズを+/-ズームするためのホットキーなどのプロパティ関連の機能強化を行う将来のリリースを本当に楽しみにしています。

@miniksa ：非常に興味深い投稿をありがとう！

Windowsがこの作業を実行するために必要な最も古くて最低レベルのAPIの近くでdarnを使用しています。

私はこれについてしばらくの間興味がありました。 さまざまなWin32API（USER32 / GDI32）を参照しているようです。 私は最近、それらがWindowsの最近のバージョン（8.0以降）で取得できるほど低レベルであるかどうか、またはこれらのAPIが他のもの（Direct2Dなど）の上に静かに変換されているかどうかについて確信が持てなくなりました。 DirectWriteなど）。 古いAPIは新しいAPIとどのように関連していますか？ そのビットを明確にすることができれば私はそれが大好きです！

@stakx 、私はUSER32とGDI32を参照しています。

詳細を確認するのに何時間も費やすことなく、頭のてっぺんから私が知っていることの大まかな概要を説明します。 そのため、これの一部は手振りの対象であり、わずかに正しくない可能性がありますが、おそらく正しい方向にあります。 すべてのステートメントは、世界がどのように機能し、意見や誤りの対象となるかについての私の個人的な知識であると考えてください。

パイプラインのグラフィック部分（GDI32）の場合、GDIのユーザーモード部分はかなり下にあります。 アプリはGDI32を呼び出し、ユーザーモード側のDLLでいくつかの作業が行われ、カーネル呼び出しがカーネルにジャンプして描画が行われます。

「他のものの上に静かに変換される」とあなたが考えている部分は、おそらく、カーネル呼び出しにぶつかると、カーネルGDIのものの束が同じものの上に再プラットフォーム化される傾向があるということですDirectXが実際にNVIDIA / AMD / Intel / etcによって処理される場合。 スタックの一番下にあるグラフィックスドライバーとGPU。 これは、WindowsVista用のWDDMの一部として提供されたグラフィックスドライバーの再アーキテクチャで発生したと思います。 GDIでまだ実際に高速であり、プラットフォームの再構築の結果として低速である呼び出しについてのドキュメントがどこかにあります。 前回そのドキュメントを見つけて確認したときは、高速のものを使用していました。

GDIに加えて、Common Controlsやcomctl32.dllのようなものがあり、より優れた宣言型フレームワークができる前に、UIを作成するための再利用可能なボタンと要素のセットを提供していたと思います。 コンソールでは実際には使用しません（右クリックメニューのプロパティシートを除く）。

DirectWriteとD2D、およびD3DとDXGI自体に関しては、これらは、ユーザーモードとカーネルモードの両方で、GDIから完全に離れたコマンドとパスの別個のセットです。 これらは、2つの間にいくつかの相互運用性の規定があることを除いて、実際には関連していません。 ただし、他のUIフレームワークのほとんどは、DirectXスタックの上に構築される傾向があります。 XAMLは確かです。 WPFはそうだと思います。 WinFormsについてはよくわかりません。 また、コンポジションスタックとウィンドウマネージャーもDirectXを使用していると思います。

パイプラインの入力/相互作用部分（USER32）に関しては、他のほとんどの新しいもの（少なくともデスクトップPCの場合）がすでに存在するものの上に構築されていることに気付く傾向があります。 USER32の主要な概念はウィンドウとウィンドウハンドルであり、すべてがウィンドウハンドルに送信されます。 デスクトップマシン（またはラップトップなど...つまり、クラシックスタイルのWindows搭載マシン）を使用している限り、ウィンドウハンドルが関係し、メッセージが浮かんでいます。つまり、USER32について話しているということです。

ウィンドウメッセージキューは、フォアグラウンドにある間にそのウィンドウに関連して発生した入力と、システム内の他のコンポーネントによってウィンドウに送信されたものの、単純なFIFO（多かれ少なかれ）です。

XAML、WPF、WinFormsなどの新しいテクノロジやフレームワークは、ウィンドウメッセージキューからメッセージを何らかの方法で受信して処理し、ワールド内でプロビジョニングしたさまざまなオブジェクトへのイベントコールバックに変換する傾向があります。

ただし、XAMLなどの他のデスクトップ以外のプラットフォームでも機能する新しいテクノロジーは、まったく異なる非USER32スタックからのものを処理する機能も備えている傾向があります。 USER32とは別の並列スタックがあり、従来のメッセージングキューとウィンドウハンドルをまったく同じように処理しない、入力と対話の発生方法に関するすべての新しいイノベーションと実現があります。 これは、CoreWindowやCoreMessagingなどのCore *ファミリー全体です。 彼らはまた、机の上にキーボードとマウスを置いた画面の前のローリングチェアでお尻を中心にしない「ユーザーとは何か」という異なる概念を持っています。

XAMLまたは他のフレームワークのいずれかを使用している場合...この複雑さはすべて自動的に処理されます。 XAMLは、DirectXを利用する方法を理解し、コンポジターおよびウィンドウマネージャーと交渉して、ユーザーに代わってクールな効果を実現します。 プラットフォームに応じて、USER32またはCore *から透過的に入力イベントを取得するかどうかを判断し、入力スタックはペン、タッチ、キーボード、マウスなどを統一された方法で処理できます。 それはあなたの人生を楽にするあらゆる種類のグローバリゼーション、アクセシビリティ、入力の相互作用などを行うために埋め込まれた規定を持っています。 ただし、低レベルに直接移動して自分で処理するか、気にしないものの処理をスキップするかを選択できます。

秘訣は、GDI32とUSER32が、限られたコマンドセットで限られた世界向けに設計されていることです。 デスクトップPCだけが存在し、キーボードとマウスを1人で操作し、VGAモニターにシンプルなグラフィックを出力しました。 したがって、conhostのように「低レベル」で直接使用するのは非常に簡単です。 新しいプラットフォームは「低レベル」で使用できますが、さまざまなフォームファクタ、複数のアクティブユーザー、複数のグラフィックアダプタなど、20年以上にわたってパーソナルコンピューティングで発生したすべてのことを説明するようになったため、桁違いに複雑になっています。とオンとオンとオンとオン。 そのため、新しいものを使用するときはフレームワークを使用する傾向があるため、頭が爆発することはありません。 彼らはあなたのためにそれを処理しますが、彼らは以前よりも多くを処理するので、ある程度遅くなります。

では、GDI32とUSER32は新しいものよりも「低い」のでしょうか。 ある種。
あなたは新しいものでそれを低くすることができますか？ ほとんどはそうですが、おそらくそうすべきではなく、そうしたくないでしょう。
新しいものは古いものの上に住んでいますか、それとも古いものは新しいものに再プラットフォーム化されていますか？ 時々および/または部分的に。
基本的に...それはあらゆるソフトウェアへの答えのようなものです...「それは軽減されていない災害であり、私たち全員が少し後退した場合、それがまったく機能することに驚かれるはずです。」 ：P

とにかく、それはある朝のための十分な散歩です。 うまくいけば、それはあなたの質問にいくらか答えて、あなたにもう少し洞察を与えました。

うまくいけば、それはあなたの質問にいくらか答えて、あなたにもう少し洞察を与えました。

@miniksa 、確かにそうだった！ 完全に理にかなっています。 それをすべて書くために時間を割いてくれてありがとう！ ：+1：

とりあえずこの問題をクローズします。 お問い合わせいただきありがとうございます。情報を楽しんでいただけてうれしいです。