Ninject y rendimiento

Estoy haciendo una revisión de código en un sitio web que tendrá muchos usuarios simultáneos, ca. 100,000 usuarios autenticados.Ninject y rendimiento

he encontrado el siguiente código de tipo:

[Inject] 
    public BusinessLayer.ILoginManager LoginManager { get; set; }

Y en global.asax.cs:

protected Ninject.IKernel CreateKernel() 
    { 
     return new StandardKernel(new ServiceModule()); 
    } 


    internal class ServiceModule : NinjectModule 
    { 

     public override void Load() 
     { 
      Kernel.Bind<IReportProxy>().To<ReportProxy>().InRequestScope(); 
     } 
    }

pregunta es: ¿El uso de Ninject afectar al rendimiento? ¿Hay situaciones en las que no deberías usar Ninject debido al rendimiento?

Fuente

2011-04-18 Shiraz Bhaiji

Como siempre sucede con las preguntas y problemas de rendimiento, no puede detectar ninguna de ellas con tan solo mirar su código. Más bien, profile su aplicación y vea dónde está el problema.

Según mi experiencia anterior, los contenedores de IoC solo suponen gastos generales de rendimiento en el inicio de la aplicación y su impacto es casi despreciable mientras se ejecuta la aplicación.

Fuente

2011-04-18 12:11:12

Es cierto, pero todos tienen diferentes API y conjuntos de características. Considere tomar una decisión basada en una serie de factores como la API, la compatibilidad con el tiempo de vida objetivo (por ejemplo, por solicitud web es agradable en aplicaciones web), el rendimiento para el uso del objetivo, la concesión de licencias, etc. – Philippe

Ninject nos causó mucho dolor relacionado con el rendimiento en el proyecto. Es uno de los DI más lento por ahí y yo fuertemente recomendaría considerar otro motor DI (por ejemplo https://github.com/ninject/ninject/issues/84)

par de cosas a tener en cuenta sobre Ninject:

Unbind/Rebind no es seguro para subprocesos (AFAIK no especificado en ningún lugar en xmldocs). Síntoma: intermitentemente puede perder algunos enlaces debido a una duplicación de clave en el diccionario interno de Kenrel.
Hacer referencia al objeto de ámbito personalizado del destino de enlace podría provocar una pérdida de memoria (este es realmente razonable, pero Ninject no es de ninguna manera útil para localizar el problema). P.ej. Enlazar un objeto que tiene una referencia permanente a HttpContext en el volumen de HttpContext.Current

También vale la pena teniendo en cuenta que el cambio a una DI diferente podría no ser factible en función del conjunto de características que terminaría usando (por ejemplo, ubicación del servicio, enlaces condicionales, ámbitos personalizados, enlaces dinámicos, etc.). Incluso si otro marco DI tiene un conjunto de características similar (por ejemplo, LightInject), la sintaxis puede ser demasiado diferente.

Fuente

2015-04-15 08:51:52 bushed

Respuesta

Cuestiones relacionadas