Lucas Ontivero: .NET

[Benchmark] Reflection Performance

Thu, 06 Sep 2007 14:40:00 GMT

[Tanslate this post to english with google]

Escribiendo el próximo post sobre el patrón DataMapper mediante reflection (lo estoy cocinando) me puse a pensar en una lista de pros y contras como así también, algunos escenarios en donde yo lo implementaria y en donde no. Entre los argumentos en contra seguramente debía figurar el hecho de que reflection tiene un costo que hay que evaluar. Yo pensaba que este argumento bien podría ponerse en la balanza junto con todos los beneficios de este patrón y pensaba argumentar también que si bien, el uso de reflection es caro, tampoco es una locura.

Pero después me saltó la duda, cuan lento puede ser el uso de reflecion en comparación con un acceso convencional? Así que primero tiré un número a la mancancha, "debe ser 6 o 7 veces mas lento..." pensé. Y me puse a buscar en google, encontré este blog y este muy buen artículo y este otro blog que que aunque también hace la prueba parece que el benchmark está distorcionado porque lo hace con una aplicación winform en la que existen al menos dos threads compitiendo (UI y el que corre nuestro código).

Pero después me acordé de un proyecto que abusaba tanto de esta técnica que tardaba 3 minutos en arrancar!! Así que tiré otro número, "nooo, debe ser como 100 veces más lento". Así que hice mi propia prueba solo seteando un field, una property e invocando un método y los números me dieron la razón, en estos caso es mucho más lento.

Los números:

En un Pentium 4 de 2.8GHz y 1 GB de RAM / Windows XP PE SP2.

El mismo test (con bucles más chicos para irme a dormir más temprano) pero en un ADM 2800 con 512 de RAM /W2003 Server PE dió el resultado de arriba.

Si se corre este test más de una vez se obtienen resultados similares aunque distintos por varias razones, en primer lugar este test compite con las otras aplicaciones por el tiempo de ejecución por lo que nunca sabemos en que parte del código el S.O. nos interrumpe, otra cosa que distorciona es el hecho de que las operaciones de acceso directo a los campos, propiedades y métodos son más rápidas por lo que tienen menos posibilidades de ser interrumpidas por el planificador del SO. Esto último hace que a veces se obtengan brechas mayores a las que se muestran.

En síntesis, reflection es, al menos en estas operaciones, unas cientos de veces más lento que un acceso "común". También lo corrí poniendo el proceso con prioridad Hight y obtuve resultados similares.

Pueden impugnar este benchmark si ven algo que esté mal. Acá va el código:

using System;
using System.Text;
using System.Reflection;

namespace Temosoft.Benchmarks
{
        class Program
        {
                static void Main(string[] args)
                {
                        DateTime startDate;
                        TimeSpan ts;
                        int max = 10000000; //int.MaxValue;

                        TestClass t = new TestClass();

                        System.Console.WriteLine("----- FIELDS ------");
                        startDate = DateTime.Now;
                        for (int i = 0; i < max; i++)
                        {
                                t.field = i;
                        }
                        ts = DateTime.Now.Subtract(startDate);
                        System.Console.WriteLine("{0, -42}: {1}", "obj.field = i;", ts.Ticks);


                        Type type = typeof(TestClass);
                        FieldInfo fi = type.GetField("field");
                        startDate = DateTime.Now;
                        for (int i = 0; i < max; i++)
                        {
                                fi.SetValue(t, i);
                        }
                        ts = DateTime.Now.Subtract(startDate);
                        System.Console.WriteLine("{0, -42}: {1}", "fieldInfo.SetValue(t, i);", ts.Ticks);


                        startDate = DateTime.Now;
                        for (int i = 0; i < max; i++)
                        {
                                typeof(TestClass).GetField("field").SetValue(t, i);
                        }
                        ts = DateTime.Now.Subtract(startDate);
                        System.Console.WriteLine("{0, -42}: {1}", "typeof(TestClass).GetField(\"field\").SetValue(t, i);", ts.Ticks);


                        System.Console.WriteLine("----- PROPERTIES --");
                        startDate = DateTime.Now;
                        for (int i = 0; i < max; i++)
                        {
                                t.Field = i;
                        }
                        ts = DateTime.Now.Subtract(startDate);
                        System.Console.WriteLine("{0, -42}: {1}", "obj.Property = i;", ts.Ticks);


                        PropertyInfo pi = type.GetProperty("Field");
                        startDate = DateTime.Now;
                        for (int i = 0; i < max; i++)
                        {
                                pi.SetValue(t, i, null);
                        }
                        ts = DateTime.Now.Subtract(startDate);
                        System.Console.WriteLine("{0, -42}: {1}", "propertyInfo.SetValue(t, i);", ts.Ticks);


                        startDate = DateTime.Now;
                        for (int i = 0; i < max; i++)
                        {
                                typeof(TestClass).GetProperty("Field").SetValue(t, i, null);
                        }
                        ts = DateTime.Now.Subtract(startDate);
                        System.Console.WriteLine("{0, -42}: {1}", "typeof(TestClass).GetProperty(\"Field\").SetValue(t, i, null);", ts.Ticks);


                        System.Console.WriteLine("----- METHODS --");
                        startDate = DateTime.Now;
                        for (int i = 0; i < max; i++)
                        {
                                t.Method1(i);
                        }
                        ts = DateTime.Now.Subtract(startDate);
                        System.Console.WriteLine("{0, -42}: {1}", "obj.Method(i);", ts.Ticks);


                        MethodInfo mi = type.GetMethod("Method1");
                        startDate = DateTime.Now;
                        for (int i = 0; i < max; i++)
                        {
                                mi.Invoke(t, new object[]{i} );
                        }
                        ts = DateTime.Now.Subtract(startDate);
                        System.Console.WriteLine("{0, -42}: {1}", "methodInfo.Invoke(t, new object[]{i} );", ts.Ticks);


                        mi = type.GetMethod("Method2");
                        startDate = DateTime.Now;
                        for (int i = 0; i < max; i++)
                        {
                                mi.Invoke(t, new object[] { i, i, i, i, i, i });
                        }
                        ts = DateTime.Now.Subtract(startDate);
                        System.Console.WriteLine("{0, -42}: {1}", "methodInfo.Invoke(t, new object[] { i, i, i, i, i, i });", ts.Ticks);

                        System.Console.ReadLine();
                }
        }

        class TestClass
        {
                public int field;
                public int Field
                {
                        set { field = value; }
                        get { return field; }
                }

                public void Method1(int i)
                {
                        field = i;
                }

                public void Method2(int i, int j, int k, int l, int m, int n)
                {
                        field = i;
                }

        }
}

Lucas Ontivero

Scripts en c#

Wed, 21 Mar 2007 13:33:13 GMT

Despues de trabajar mucho tiempo con scripting y pasar a .NET, he llegado a extrañar esos pequeños bloquecitos de código, sobre todo a la hora de automatizar pequeñas tareas para las cuales ni siquiera te dan ganas de abrir un Visual Studio. Por ejemplo, hoy queria computar un hash (3 lineas de código) y realmente me dió tanta pero tanta fiaca hacer una solucion en VS y dije "Si pudiera usar el framework de .NET desde un script que feliz que seria" así que buscando y buscando encontré "Scripts en c#!!!". Casi me largo a llorar, es que los scripts son muy grosos cuando:

vamos a cambiar el código con mucha frecuencia.
el código es muy chico y puntual
no nos interesa protegerlo
son ideales para tareas de administración
cuando no tenemos vs
cuando no nos interesa proteger el código
y deben existir 500.00 razones

Por otra parte, que raro que Microsoft no brinde la posibilidad de programar los WSH con c# o vb.net, no les parece?
Bueno, además de tener "todo" el framework a nuestra disposición hace que sea muy superior a los .vbs o .wsc porque por ejempo podemos trabajar con ws, crear formularios, acceder a db con ado.net, etc. En sintesis, hacemos de todo.
Una alegria mas a mi vida. Gracias.

Un resumen de ObjectBuilder Framework

Wed, 01 Nov 2006 03:13:16 GMT

Con este post pretendo comenzar un recorrido rápidos (que probablemente después continue) por uno de los assembies creado por el grupo de Patterns & Practices de Microsoft que mas me ha sorprendido. Se trata del ObjectBuilder.dll el cual forma parte del core de la Enterprise Library, del Composite UI Application Block (CAB) y del Mobile Client Software Factory y probablemente de cuanto futuro Application Block libere P&P.

Este assembly es el encargado de realizar la creación de objectos y la inyección de dependecias (DI).

Podríamos ver al ObjectBuilder (extremadamente simplificado) como una lista de acciones ("estrategias") que permiten ejecutar una variada gama de operaciones sobre los objetos cuando estos son creados. Estas acciones son las que:

Aseguran la creación de instancias de clases concretas cuando se especifica un tipo abstracto.
Aseguran el retorno de instancias existentes cuando son del tipo adecuado o crea una instancia nueva si así se especifica.
Aseguran la ejecución del constructor adecuado. Puesto que al crear una instancia de clase, se selecciona de manera inteligente el constructor que debe invocar aún cuando existan mas de uno. Si el constructor recibe parámetros, los resuelve y se los pasa.
Aseguran la asignación de valores apropiados a las propiedades públicas que contienen atributos específicos y ejecuta métodos automáticamente.
Aseguran la notifica a todo objeto que implemente la interface IBuilderAware cuando una estratégia es ejecutada sobre el objeto.
Además, provee la posibilidad de deshacer las acciones llevadas a cabo sobre un objeto ejecutando el método TearDown sobre la cadena de responsabilidades invertida.

En otras palabras, ObjectBuilder simplicica la creación e inicialización de objetos. Y nos facilita la vida permitiéndonos tener servicios como clases desacopladas y despreocupándonos de los detalles de creación e inicialización de instancias.

Las clases más significativas de objectBuilder son a mi entender las siguientes:

Estrategias que derivan de BuilderStrategy
- CreationStrategy: Crea un objeto de un tipo dado y lo registra en en locator (Si ya estaba creado también lo registra). Si no encuentra una politica de como se debe crear el objeto entonces simplemente obtiene por reflection el primer constructor y resuelve los parámetros que debe recibir para luego "invocar" al constructor como si fuera un método pasándole estos parámetros. ¿Hace magia o no hace magia?,.... Increible.
  Ahora, si encuentra una política para construir el objeto (una ConstructorPolicy la cual almacena los tipos de datos de los parámetros que recibe el constructor) puede obtener el constructor adecuado para inicializar el objeto creado. La política fue creada en su momento por la estrategia ConstructorReflectionStrategy la cual, como su nombre lo sugiere, recorre mediante reflection la clase en busca de atributos customs
- SingletonStrategy: Busca por una política (ISingletonPolicy) relacionada al objeto tratado en el locator y si existe retorna la instancia.
- PropertySetterStrategy: Busca la instancia adecuada para establecer una propiedad pública en el objeto creado.
- MethodExecutionStrategy: Ejecuta un método en un objeto resolviendo y pasándole los parámetros adecuados.
- BuilderAwareStrategy: Asiva (ejecutando un método obviamente) a los objetos cuando se ha aplicado una estratégia sobre ellos. Todos los objetos interesados en realizar acciones al final de la ejecución de una estrategia deben implementar la interface IBuilderAware.

Las demás estrategias son las encargadas de completar las politicas sobre los objetos mediante reflection y se ejecutan en el estado de PreCreation.

PropertyReflectionStrategy
MethodReflectionStrategy
ConstructorReflectionStrategy

Builder:
Esta clase contiene una lista de políticas y una lista de estratégias genéricas de un estado en particular.
Estos pueden "estados" ser: PreCreation, Creation, Initialization, PostInitialization
Cada lista de estrategias es para un "estado" de los mencionados y contiene "IBuilderStrategy (s)" aplicables a esos estados.

StrategyList:
Posee un diccionario con tantas entradas como "estados" haya resgistrados (es decir, 4) como key y como value una lista de estrategias (List<IBuilderStrategy>).

La definición de estos es: Dictionary<TStageEnum, List<IBuilderStrategy>> stages;

Uno de los métodos mas importantes de la clase StrategyList es MakeStrategyChain el cual crea y devuelve un objeto IBuilderStrategyChain que contiene una lista con todas las estrategias de todos los estados. Esta lista es la llamada cadena de responsabilidades que se iterará invocanco a los métods DoBuildUp de cada estrategias contenida en la lista.
El otro método importante es MakeReverseStrategyChain el cual retorna la misma cadena pero ordenada de manera inversa y la iterará la clase Builder invocando al método TearDown de cada estrategia contenida es esta cadena para deshacer la acción realizada por estas.

IBuilderStrategy:
Esta es la interface que deben implementar las estratégias. Exige 2 métodos:
- object BuildUp(IBuilderContext context, Type typeToBuild, object existing, string idToBuild)
  El cual es llamado durante la ejecución de la cadena de responsabilidades para realizar la acción propia de la estrategia.
- object TearDown(IBuilderContext context, object item)
  El cual es llamado durante la ejecución de la cadena de responsabilidades para deshacer la acción propia de la estrategia.
BuilderContext
Esta clase contiene:
La cadena de responsabilidades (IBuilderStrategyChain)
Las políticas (PolicyList) y
El Localizador (IReadWriteLocator)

Locator:
Esta clase no es mas que un diccionario que contiene como key el tipo de dato y como valor una instacia de ese tipo. Algo así como un pool de objetos sobre los cuales se aplicarán las estrategias. Este diccionario se mantiene con WeakReferences para que cualquier objeto almacenado pueda ser recogido por el GC.

Resurrection - Permitiendo lo prohibido

Fri, 22 Sep 2006 05:48:02 GMT

Curiosiando un poco por algunas publicaciones de microsoft en la web me topé con el concepto de "Resurrection". Este, que parece un buen nombre candidato para la próxima Matriz, no es en realidad otra cosa que una consecuencia, a mi entender poco deseable (Uds. pueden pensar lo contrario), del algoritmo de recolección de basura del CLR.

Se dice que un objeto ha resucitado cuando luego de que el GC lo ha identificado como basura y ha ejecutado el destructor, el objeto sigue vivo y no es eliminado de la memoria. Esta situación se presenta en el siguiente código:

    class Program
    {
        static public ClassA refToObjectA;
        static void Main(string[] args)
        {
            refToObjectA = new ClassA();
            refToObjectA = null;
            GC.Collect();
            GC.WaitForPendingFinalizers();
            Console.WriteLine(refToObjectA.refToObjectB.val);
            refToObjectA = null;
            GC.Collect();
            GC.WaitForPendingFinalizers();
        }
    }

    public class ClassA
    {
        public ClassB refToObjectB;
        public ClassA()
        {
            refToObjectB = new ClassB();
        }

        ~ClassA()
        {
            Console.WriteLine("Bye A!");
            Program.refToObjectA = this;
        }
    }

    public class ClassB
    {
        public String val;
        public ClassB()
        {
            val = "Hola";
        }

        ~ClassB()
        {
            Console.WriteLine("Bye B!");
            val = "Chau";
        }
    }

Como en este caso el destructor de la ClassA tiene la linea:
Program.refToObjectA = this;
se tiene una referencia al objeto que se estaba por recolectar y por lo tanto, el GC no debe eliminarlo. El problema es que como este objeto ya se habia seleccionado para colectarlo, y se quitó de la cola de finalización (una estructura que mantiene la lista de todos los objetos cuyos destructures deben invocarse), la proxima vez que el GC lo deba recoger ya no volverá a ejecutarse el destructor.

En el ejemplito de arriba no habría problemas pero estos pueden presentarse en casos que se manejen recursos como conexiones a DBs, Archivos u otros que pueden ser liberados en el destructor y luego, una vez resucitado el objeto, intentar accederlos.

Para solucionar este problema (que no se vuelve a ejecutar el destructor) existe el método GC.ReRegisterForFinalize el cual le dice al GC que cree una nueva entrada en la cola de finalización para el objeto que se le indique por parámetro pero a mi entender soluciona un inconveniente a la vez que posibilita la aparición de otro que ocurre cuando este se invoca mas de una vez por cada resurrección o bien se lo invoca cuando no existen resurrecciones. En este caso el destructor del objeto indicado se ejecutará tantas veces como invocaciones al método GC.ReRegisterForFinalize se hayan realizado.