He estado buscando un poco para algunas pruebas de rendimiento sobre tareas típicas de AOP. Aunque no he podido encontrar ninguno, ¿podría ayudarme? Estoy pensando principalmente en Castle, Unity y quizás PostSharp, aunque podría ser demasiado costoso para mi proyecto.Sobrecarga de rendimiento AOP
No he visto ninguna comparación cuantitativa, también, por lo que esta respuesta probablemente esté lejos de completarse.
Es difícil comparar el rendimiento del castillo o Unidad con PostSharp - Castillo y la Unidad utilizar runtime weaving por proxy dinámico y PostSharp implica una sobrecarga at compile stage. Entonces, si el rendimiento es crucial para usted, las soluciones compiladas como PostSharp siempre serán mejores. La generación de proxies AOP en tiempo de ejecución significa la generación dinámica de código IL y el uso de reflexión intensa.
Por lo tanto, las pruebas de rendimiento que puedan tener sentido tienen que comparar soluciones usando la misma técnica: puede intentar comparar Castle Dynamic Proxy y la implementación del proxy Unity Interception.
No conozco bien el anterior, pero en el caso de este último, todavía hay tres escenarios diferentes para comparar: proxies transparentes (MarshalByRefObject), proxies de interfaz y proxies de subclases, cada uno con su propio conjunto de escenarios de uso y su propios gastos generales de rendimiento. Según lo que he leído, el proxy transparente es terriblemente lento y no debe usarse en escenarios AOP. Los proxies de interfaz y subtipificación generan algunos IL sobre la marcha y esto es lo mismo que Castle DP, así que creo que las diferencias no deberían ser tan grandes (pero de nuevo, no hay resultados cuantitativos aquí).
Si está buscando una herramienta AOP liviana, hay un artículo "Agregar aspectos al objeto usando Dynamic Decorator" (http://www.codeproject.com/KB/architecture/aspectddecorator.aspx). Es delgado y flexible.
Describe un enfoque para agregar aspectos al objeto en tiempo de ejecución en lugar de agregar aspectos a la clase en tiempo de diseño. La ventaja de este enfoque es que usted decide si necesita un aspecto cuando usa un objeto.
La mayoría de las herramientas de AOP actuales definen aspectos a nivel de clase en el tiempo de diseño de clase. Y no tienes la flexibilidad cuando usas un objeto de las clases.
Si el rendimiento es crucial en su proyecto, asegúrese de que su uso del AOP esté orientado al rendimiento porque la sobrecarga de un Marco AOP raramente es pobre a menos que el uso no sea compatible.
Por ejemplo, si usa DynamicProxy, tiene la opción de llamar al tratamiento de respaldo mediante reflexión o llamando al método Proceed(). Altera de forma diferente el rendimiento.
Otro ejemplo: la mayoría de los frameworks de AOP le dan el MethodInfo a su "consejo". La forma en que obtienen esta metedata puede alterar su rendimiento porque GetMethodFromHandle puede ser muy malo en tratamientos de extrema concurrencia (acceso de diccionario con un bloqueo).
Otra cosa importante a tener en cuenta: utilizar el método adaptado para overlod consejo porque si AOP marco tiene que preparar demasiada información (argumento, MethodInfo, ...) lo va a pagar (sobrecarga de rendimiento). Desafortunadamente, a veces no hay una buena interfaz de usuario final para implementar un evento de asesoramiento de rendimiento si la interceptación fue perfecta.
Para obtener más información, en la publicación when-is-aop-code-executed, doy mis comentarios sobre el problema de rendimiento de AOP Framework.
Define las pruebas de rendimiento. ¿Tiempo de compilación o tiempo de ejecución? – TomTom
PostSharp teje tus aspectos en tu código. No hay ninguna sobrecarga de AoP real involucrada. – Amy