Terminal: Escribir dentro del terminal WSL predeterminado se siente increíble, ¿por qué es mejor que cualquier otra aplicación?

Realmente no me importa cuando alguien viene y decide decirnos que estamos haciendo un buen trabajo en algo. Todos los días escuchamos tantas quejas de que una publicación como esta es un soplo de aire fresco. ¡Gracias por tu agradecimiento!

Además, me complace discutir esto con usted hasta que esté completamente harto de leerlo. Por favor pregunte cualquier seguimiento que desee. Me encanta parlotear sobre mi trabajo. :PAGS

Si tuviera que hacer una conjetura sobre lo que nos hace más rápidos que casi cualquier otra aplicación en Windows para poner su texto en la pantalla ... ¡diría que es porque ese es literalmente nuestro único trabajo! También probablemente porque estamos usando casi las API de nivel más antiguo y más bajo que Windows tiene para realizar este trabajo.

Casi todo lo demás que ha enumerado tiene algún tipo de capa o marco involucrado, o muchas, muchas capas y marcos, cuando comienza a hablar de Electron y Javascript. Nosotros no

Tenemos una ventana desnuda, súper no especial, sin controles adicionales adjuntos. Recibimos nuestras claves apenas por encima del kernel dado que las estamos procesando desde mensajes de ventana y no desde algún tipo de marco de eventos común a prácticamente cualquier otro marco de interfaz de usuario más complicado que el nuestro (WPF, WinForms, UWP, Electrón). Y volcamos nuestro texto directamente en la superficie de la ventana usando PolyTextOut de GDI sin lujos.

Incluso notepad.exe tiene múltiples controles en su ventana como mínimo y probablemente (no he mirado) está usando algún tipo de marco de biblioteca en el control de edición para averiguar su diseño de texto (que probablemente esté usando otra biblioteca marco de apoyo a la internacionalización ...)

Por supuesto, esto también significa que tenemos compensaciones. No admitimos texto totalmente internacional como lo harán casi todas las demás aplicaciones. RTL? No hay zona de acceso en este momento. ¿Pares sustitutos y emoji? Estamos llegando, pero todavía no. ¿Guiones índicos? No

¿Por qué somos así? Por un lado, conhost.exe es tan viejo como la suciedad. Tiene que usar la capa inferior de metal desnudo de todo porque se creó antes de que se crearan la mayoría de esos otros marcos. Y también mantiene el nivel más bajo / mínimo posible porque es prácticamente lo primero que uno debe mencionar al abrir una nueva edición de sistema operativo o dispositivo antes de tener todas las cosas buenas como los marcos o lo que esos marcos requieren para funcionar. También está escrito en C / C ++, que es lo más bajo y básico posible.

¿Esta mejora de la interfaz de usuario llegará a otras aplicaciones en Windows? Es casi seguro que no. Tienen demasiadas cosas que son buenas y malas. Estoy celoso de su capacidad para llamar a un método y diseñar texto de una manera sencilla en cualquier idioma sin calcular manualmente los píxeles o preocuparse por los estilos que se aplican a su fuente. Pero mis cálculos manuales de píxeles, las matemáticas de la región sucia, la locura de la región de desplazamiento y más hacen que vayamos más rápido que ellos. También estoy celoso de que cuando alguien dice "oye, ¿puedes agregar una barra de estado en la parte inferior de la ventana?", Pueden hacer clic y arrastrarla a su lugar con su marco de interfaz de usuario y simplemente funcionará donde para nosotros, es Siempre ha sido un elemento de la acumulación y me provoca acidez estomacal que pensar en implementar.

¿Intentaremos evitar que retroceda? ¡Si! Ahora mismo es una especie de proceso manual. Identificamos que algo se está volviendo lento y luego sacamos WPR y comenzamos a

Como acotación al margen, @bitcrazed quiere que automaticemos las pruebas de rendimiento de alguna manera específica conhost, pero todavía no he descubierto un entorno controlado para hacer esto. El sistema de ingeniería de Windows ejecuta pruebas de rendimiento todas las noches que nos brindan una forma aproximada de saber si estropeamos algo en todo el sistema operativo, y técnicamente ofrecen una forma detallada para que insertemos nuestras propias pruebas de rendimiento ... pero yo simplemente no he llegado a eso todavía. Si tiene una idea de cómo podemos hacer esto de forma automatizada, soy todo oídos.

Si hay algo más que le gustaría saber, hágamelo saber. Podría seguir todo el día. Eliminé como 15 tangentes de esta respuesta antes de publicarla ...

Hablando de las API de Windows de bajo nivel, descubrí que todos los componentes del modo de usuario de la consola (conhost.exe, cmd.exe ...) y WSL (wsl.exe, LxssManager.dll ...) usan C ++ _STL_ enormemente. Por ejemplo, en la manipulación de cadenas, asignación de memoria, tablas virtuales, etc. ¿Habrá alguna mejora en el rendimiento si solo se utiliza C?

Yo no los consideraría como que usan C ++ STL "enormemente". Definitivamente usan algunas de las colecciones y quizás un poco de manipulación de cadenas y un algoritmo aquí o allá. Siento que STL es mucho más que esos pocos bits.

Pero de todos modos ... la mayoría de las cosas que describe fueron escritas directamente en C hace un tiempo. Hemos estado usando selectivamente C ++ y STL en más y más de ellos como una compensación consciente. Siempre que sepamos bien lo que están haciendo las plantillas bajo el capó y hagamos un uso cuidadoso de las correctas, generalmente solo estamos negociando una cantidad muy pequeña de rendimiento mientras obtenemos una cantidad significativa de seguridad y facilidad de programación.

La seguridad es en realidad la gran razón por la que usamos plantillas STL en lugar de intentar crear nuestras propias estructuras siempre que sea posible. El uso de las plantillas STL para colecciones y cadenas generalmente nos otorga una verificación de límites que, de lo contrario, tendría que realizarse manualmente de manera propensa a errores (¡o no se haría en absoluto!)

Además, no estoy estrictamente seguro de que tener 17 implementaciones de listas enlazadas y colas diferentes dentro del código de la consola cuando era C directo fuera en general mejor para el rendimiento que usar std :: queue y std :: list hoy. Probablemente consumió más espacio en el disco para cada implementación individual, que es un tipo diferente de problema de rendimiento (almacenamiento y E / S de carga de página).

Muchas gracias por tomarse el tiempo para escribir esa respuesta, y no hay problema con los elogios.

Durante los últimos meses estuve buscando una buena configuración de terminal, y creo que ubuntu.exe con tmux es lo más cercano a la perfección que se puede conseguir con las herramientas que tenemos hoy. La terminal ubuntu.exe sí es increíblemente rápida y tmux le brinda todas las ventajas de calidad de vida (pestañas, paneles divididos, búsqueda de búfer, etc.).

Espero con ansias futuras versiones que hagan que los temas de color sean más compatibles y mejoras relacionadas con las propiedades, como teclas de acceso rápido para hacer zoom +/- en el tamaño de fuente.

@miniksa : ¡Gracias por una publicación muy interesante!

estamos utilizando casi las API de nivel más antiguo y más bajo que Windows tiene para realizar este trabajo.

He sentido curiosidad por esto por un tiempo. Parece que se está refiriendo a las distintas API de Win32 (USER32 / GDI32). Últimamente no estoy seguro de si siguen siendo de tan bajo nivel como se puede obtener en las versiones recientes de Windows (8.0 y posteriores), o si estas API se han convertido silenciosamente para ubicarse sobre otras cosas (como Direct2D, DirectWrite, etc.). ¿Cómo se relacionan las API más antiguas con las más nuevas? ¡Me encantaría si pudieras aclarar eso!

@stakx , me refiero a USER32 y GDI32.

Te daré una descripción general de lo que sé de la cabeza sin pasar horas confirmando los detalles. Como tal, algo de esto está sujeto a agitar las manos y podría ser levemente incorrecto, pero probablemente esté en la dirección correcta. Considere que cada declaración es mi conocimiento personal sobre cómo funciona el mundo y está sujeta a opiniones o errores.

Para la parte de gráficos de la canalización (GDI32), las partes del modo de usuario de GDI están bastante bajas. La aplicación llama a GDI32, se realiza algo de trabajo en esa DLL en el lado del modo de usuario, luego una llamada del kernel salta al kernel y se produce el dibujo.

La parte en la que está pensando con respecto a "convertir silenciosamente para sentarse encima de otras cosas" es probablemente que una vez que accedemos a las llamadas del kernel, un montón de cosas de GDI del kernel tienden a ser re-plataforma sobre las mismas cosas que DirectX cuando en realidad lo maneja NVIDIA / AMD / Intel / etc. controlador de gráficos y la GPU en la parte inferior de la pila. Creo que esto sucedió con la re-arquitectura del controlador de gráficos que vino como parte de WDDM para Windows Vista. Hay un documento por ahí sobre qué llamadas siguen siendo realmente rápidas en GDI y cuáles son más lentas como resultado del cambio de plataforma. La última vez que encontré ese documento y lo comprobé, estábamos usando los más rápidos.

Además de GDI, creo que hay cosas como Common Controls o comctl32.dll que proporcionaron a la gente conjuntos reutilizables de botones y elementos para hacer sus UI antes de que tuviéramos marcos declarativos más agradables. Realmente no los usamos en la consola (excepto en la hoja de propiedades fuera del menú del botón derecho).

En cuanto a DirectWrite y D2D y D3D y DXGI, son un conjunto separado de comandos y rutas que están completamente al lado de GDI tanto en modo de usuario como de kernel. No están realmente relacionados, aparte de que hay algunas disposiciones de interoperabilidad entre los dos. Sin embargo, la mayoría de nuestros otros marcos de interfaz de usuario tienden a construirse sobre la pila de DirectX. XAML es seguro. Creo que WPF lo es. No estoy seguro de WinForms. Y creo que la pila de composición y el administrador de ventanas también usan DirectX.

En cuanto a la parte de entrada / interacción de la canalización (USER32), tiendo a encontrar que la mayoría de las otras cosas más nuevas (al menos para PC de escritorio) se construyen sobre lo que ya está allí. El concepto principal de USER32 son las ventanas y las manijas de las ventanas y todo se envía a una manija de la ventana. Siempre que esté en una máquina de escritorio (o una computadora portátil o lo que sea ... me refiero a una máquina de estilo clásico con Windows), hay un identificador de ventana involucrado y mensajes flotando y eso significa que estamos hablando de USER32.

La cola de mensajes de la ventana es solo un FIFO directo (más o menos) de cualquier entrada que haya ocurrido relevante para esa ventana mientras está en primer plano + lo que otros componentes del sistema hayan enviado a la ventana.

Las tecnologías más nuevas y los marcos como XAML y WPF y WinForms tienden a recibir los mensajes de la cola de mensajes de la ventana de una forma u otra, procesarlos y convertirlos en devoluciones de llamada de eventos a varios objetos que han aprovisionado dentro de su mundo.

Sin embargo, las tecnologías más nuevas que también funcionan en otras plataformas que no son de escritorio como XAML tienden a tener la capacidad de procesar cosas de una pila que no es USER32 completamente diferente también. Hay una pila paralela separada para USER32 con todas nuestras nuevas innovaciones y realizaciones sobre cómo debe ocurrir la entrada y la interacción que no trata exactamente de la misma manera con las colas de mensajería clásicas y los manejadores de ventanas. Esta es toda la familia Core * de cosas como CoreWindow y CoreMessaging. También tienen un concepto diferente de "qué es un usuario" que no está tan centrado en su trasero en una silla rodante frente a una pantalla con un teclado y un mouse en el escritorio.

Ahora, si está en XAML o en uno de los otros Frameworks ... toda esta complejidad se maneja por usted. XAML descubre cómo dibujar en DirectX por usted y negocia con el compositor y el administrador de ventanas para obtener efectos geniales en su nombre. Averigua si debe obtener sus eventos de entrada de USER32 o Core * o lo que sea de forma transparente, dependiendo de su plataforma y las pilas de entrada pueden manejar lápiz, toque, teclado, mouse, etc. de una manera unificada. Tiene disposiciones en su interior integradas para hacer todo tipo de globalización, accesibilidad, interacción de entrada, etc., cosas que le facilitan la vida. Pero puede optar por ir directamente al nivel inferior y manejarlo usted mismo u omitir el manejo de lo que no le importa.

El truco es que GDI32 y USER32 fueron diseñados para un mundo limitado con un conjunto limitado de comandos. Las computadoras de escritorio eran lo único que existía, un solo usuario en el teclado y el mouse, salida de gráficos simples a un monitor VGA. Por lo tanto, usarlos directamente en el "nivel bajo" como lo hace conhost es bastante fácil. Las nuevas plataformas podrían usarse en el "nivel bajo" pero son órdenes de magnitud más complicadas porque ahora dan cuenta de todo lo que ha sucedido con la computación personal en más de 20 años como diferentes factores de forma, múltiples usuarios activos, múltiples adaptadores de gráficos, y sigue y sigue y sigue y sigue. Por lo tanto, tiende a usar un marco cuando usa las cosas nuevas para que su cabeza no explote. Lo manejan por usted, pero manejan más que nunca antes, por lo que son más lentos hasta cierto punto.

Entonces, ¿GDI32 y USER32 son "más bajos" que el material nuevo? Algo así como.
¿Puedes llegar tan bajo con las cosas más nuevas? En su mayoría sí, pero probablemente no debería y no quiere.
¿Lo nuevo vive sobre lo viejo o lo viejo se transforma en lo nuevo? A veces y / o parcialmente.
Básicamente ... es como la respuesta a cualquier software ... "es un desastre absoluto y si todos retrocedimos un momento, deberíamos sorprendernos de que funcione". :PAGS

De todos modos, ya es suficiente paseo por una mañana. Con suerte, eso respondió de alguna manera a sus preguntas y le dio un poco más de información.

Con suerte, eso respondió de alguna manera a sus preguntas y le dio un poco más de información.

@miniksa , ¡de hecho! Tiene perfecto sentido también. ¡Muchas gracias por tomarse el tiempo de escribir todo eso! : +1:

Voy a cerrar este tema por ahora. Gracias por la consulta y me alegra que haya disfrutado de la información.