.net - Rendimiento de las operaciones asincrónicas
asynchronous filestream (3)
¿Está seguro de que realizó una evaluación comparativa de su operación de copiado correctamente? Cualquier operación asíncrona solo crea un nuevo hilo y ejecuta la operación en un nuevo hilo mientras deja el hilo principal para hacer otras cosas.
Las operaciones asíncronas en su mayoría dan algunas simplificaciones (menos líneas de código) sobre la creación del hilo, pero no deberían afectar el rendimiento más que la creación de un nuevo hilo.
Una de las características de la programación asíncrona en .NET es guardar hilos durante la ejecución de la operación de larga ejecución. La clase FileStream se puede configurar para permitir operaciones asincrónicas, que permiten ejecutar (p. Ej.) Una operación de copia sin utilizar virtualmente ningún subproceso. Para mi sorpresa, descubrí que la ejecución de la copia en secuencia asíncrona no solo es más lenta, sino que también utiliza más potencia de procesamiento que el equivalente de copia en secuencia sincrónica.
¿Se realizaron pruebas comparativas para comparar una ejecución de operación sincrónica vs asincrónica (archivo, red, etc.)? ¿Realmente tiene sentido realizar una operación asíncrona en lugar de abarcar un hilo separado y realizar una operación síncrona en el entorno del servidor si la operación asincrónica es mucho más lenta que la síncrona?
Citando el artículo que incluyó en su comentario a la respuesta de @ Alex.
En situaciones donde se espera que una solicitud de E / S tome una gran cantidad de tiempo, como una actualización o respaldo de una base de datos grande o un enlace de comunicaciones lento, la E / S asíncrona es generalmente una buena forma de optimizar la eficiencia del procesamiento. Sin embargo, para operaciones de E / S relativamente rápidas, la sobrecarga de procesar las solicitudes de E / S del núcleo y las señales del kernel puede hacer que las E / S asíncronas sean menos beneficiosas, particularmente si se necesitan realizar muchas operaciones de E / S rápidas. En este caso, la E / S síncrona sería mejor. Los mecanismos y detalles de implementación de cómo llevar a cabo estas tareas varían según el tipo de identificador de dispositivo que se use y las necesidades particulares de la aplicación. En otras palabras, generalmente hay varias formas de resolver el problema.
FWIW, creo que @Alex tiene razón en que hay otro hilo que ejecuta el código del kernel asociado con su solicitud de E / S. Sin embargo, ese hilo no es administrado por su aplicación. El hilo que ejecuta el código del núcleo puede bloquearse en una solicitud de E / S del dispositivo y esperar a que el hardware real complete la solicitud antes de señalar el hilo del modo de usuario, pero aún así sigue allí.
El uso de subprocesos asincrónicos no debe considerarse como una forma de aumentar la velocidad de una solicitud en particular, sino como una forma de aumentar la eficiencia general al permitir que su aplicación continúe procesando otras tareas mientras espera una E / S relativamente lenta.
En realidad, las condiciones bajo las cuales el archivo I / o será realmente asíncrono son bastante específicas, incluso en el nivel nativo de Win32. Vea este artículo para más detalles.