¿Deberíamos cambiar para usar E/S asíncronas de forma predeterminada?
Con las ventajas de la E/S asíncrona y ahora que es bastante fácil codificar y componer (usando los métodos Await y TAP), me pregunto si deberíamos usar asíncrono de forma predeterminada y solo ajustar el rendimiento usando sincronización cuando sea necesario.
Async I/O libera el hilo de llamada y permite hacer otra cosa mientras se espera el resultado. Por otro lado, la E/S asíncrona es un poco más lenta que la sincronización.
Para imponer interfaces de usuario responsivas, los diseñadores de WinRT consideraron aceptable ofrecer métodos solo asíncronos.
AFAIK La E/S de archivos de Windows internamente es asíncrona. Al mirar esto ingenuamente, no me queda claro por qué la E/S de archivos asíncronos en .NET debería ser más lenta que la sincronización.
Generalmente prefiero la simplicidad y la robustez y solo ajusto el rendimiento cuando es necesario. En el pasado usábamos la sincronización de forma predeterminada, con la excepción de llamar a algunos servicios y donde plataformas como el teléfono imponían la sincronización. Rara vez ajustamos usando async.
Usar IO asíncrono se ha vuelto muy fácil con C# 5, pero todavía existe un costo de productividad asociado. Por ejemplo, debe agregar nuevas palabras clave donde antes no eran necesarias. Tienes que cambiar el tipo de devolución de tu método.
Si luego decide que un método debe realizar IO, debe cambiar toda la cadena de llamadas para cambiar a asíncrono. Es un cambio no local que se extiende a otros módulos.
No puedes perfilar IO asíncrono. Las herramientas de creación de perfiles no detectan nada. Si pausa el depurador, no habrá nada en ninguna de las pilas de subprocesos. Nadie parece estar haciendo nada. Esto se debe a que una IO asíncrona no contiene un hilo. Es sólo una estructura de datos (un objeto en el kernel).
La decisión también depende del tipo de solicitud. En una aplicación WinForms o WPF, prefiero utilizar async porque se integra muy bien en el hilo de la interfaz de usuario.
En una configuración ASP.NET/WCF, la principal ventaja es que no agota el grupo de subprocesos mientras llama a servicios backend de larga duración. Si no tiene ese problema, y creo que esto es bastante raro, obtendrá muy poco con la E/S asíncrona. De hecho, pierdes rendimiento por defecto.
En un entorno Metro, la decisión se ha tomado por usted. Microsoft (legítimamente) optó por cambiar la productividad de los desarrolladores por la experiencia del usuario.
Entonces no es una decisión clara. Los pros y los contras son bastante débiles en este momento. Por ese motivo me abstengo de dar una recomendación inequívoca. Depende mucho del caso concreto.
Recomendaría usarlo asynccuando tenga una operación naturalmente asíncrona y, en caso contrario, código síncrono. Es cierto que asynces un poco más lento, pero en la mayoría de los casos es como "subir el volumen de la radio de tu Hummer" más lento.
En programas de UI, asyncaumenta la capacidad de respuesta. En aplicaciones de servidor, asyncaumenta la escalabilidad.
AFAIK La E/S de archivos de Windows internamente es asíncrona. Al mirar esto ingenuamente, no me queda claro por qué la E/S de archivos asíncronos en .NET debería ser más lenta que la sincronización.
El código asincrónico es más lento porque tiene que asignar estructuras para rastrear la operación asincrónica; El código sincrónico simplemente usa el hilo actual (y su pila). Entonces, la operación en sí no es más lenta, pero en general hay una ligera disminución de la velocidad debido a una mayor presión sobre el recolector de basura.
Generalmente prefiero la simplicidad y la robustez y solo ajusto el rendimiento cuando es necesario.
Estoy de acuerdo. Si tiene una operación que es naturalmente asincrónica (como E/S), exponga una asyncAPI. Y si tiene una operación que es naturalmente síncrona, exponga una API síncrona. Stephen Toub tiene un par de publicaciones de blog excelentes sobre esto ( aquí y aquí ).
