A menudo al hablar de optimización de código se habla del inlining (código en línea) como técnica de optimización que realiza el del JIT, pero ... en que consiste?

Pues se trata de substituir el código de una llamada a función por el cuerpo de dicha función, de forma que se evita el paso de parámetros y manejo de bloques de activación. Una de las ventajas de trabajar distrubuyendo el código en funciones es su posterior reutilización, pero a la hora de compilar, si las funciones son pequeñas pueden crear una perdida de rendimiento grande en comparación a la ventaja de la reutilización de código, por lo que muchos compiladores realizan este proceso de inlining para determinadas funciones. Esto se aplica también a las propiedades y sus get/set, que suelen ser pequeños métodos.

Mas...

Parece ser que el primer Serivce Pack para Windows Vista ya esta en Beta y estará disponible en unas semanas en TechNet y para los subscriptores de MSDN, la versión final entre finales del 2007 y finales del 2008. Ocupará 1GB y requerirá 7GB libres para la instalación ... casi nada.

Más info, en Ars Technica y BandaAncha.ST.

¿Era necesario ya? La gente cree que sí, y de hecho, 1GB (que además será comprimido...) es mucho parche. Personalmente solo he probado la version Home, y no me ha disgustado pero tampoco pagaría por migrar mi Windows XP Professional. En cualquier caso las cifras hablan, y el balance de vulnerabilidades en el tiempo de vida de Vista es mucho menor que XP con sus mismos días de vida, lo cual ratifica las declaraciones de Microsoft sobre que es el Windows más seguro.

Leo através del blog de Rico Mariani que JD Meier ha anunciado la versión final de la guía Performance Testing Guidance for Web Applications, que se suma al proyecto Performance Testing Guidance.

Estas guías proponen metodologías y técnicas para hacer tests de rendimiento en aplicaciones Web y Windows por medio de las herramientas que provee Visua Studio 2005 y Visual Studio 2005 Team System.

He estado echando un vistazo y ambos tienen muy buena pinta, como muestra este How To: Identificar funciones causantes de un cuello de botella por alto consumo de tiempo de usuario de CPU en aplicaciones servidor en un entorno de producción.

Merece la pena leer este trabajo.

Como ya había dicho anteriormente, hay un sin fin de lenguajes con los que se pueden programar en .NET, pero no todos siguen las mismas reglas, por ejemplo, hay unos que son case-sensitive(ie:C#) y otros case-insensitive (VB) ... Imaginad que escribo una librería .dll en C# y mi cliente la usará en su proyecto ASP.NET en VB (mis dos enemigos juntos xD) ..., imaginad que en esa librería he incluido dos métodos públicos con mismo nombre y parámetros que se diferencian en que uno empieza por mayúsculas y otro en minúsculas ... ¿que pasaría al abrirlo con VB? Pues que no podría diferenciarlo.

Para esto existe el CLS (Common Language Specification), que "...es una especificación estandarizada que describe un entorno virtual para la ejecución de aplicaciones, cuya principal característica es la de permitir que aplicaciones escritas en distintos lenguajes de alto nivel puedan luego ejecutarse en múltiples plataformas tanto de hardware como de software sin necesidad de reescribir o recompilar su código fuente..." (Vía Wikipedia)

Para ayudar a cumplir con el CLS existe el atributo a nivel de ensamblado CLSCompliant, que hará que el compilador nos avise en tiempo de diseño con "Warnings" en aquellos puntos donde infringimos alguna regla del CLS. Este es uno de esos casos donde ... no cuesta tanto hacer las cosas bien :D

Mas...

En cualquier caso, no deja de ser un experimento curioso e intersante en un sentido intrínsecamente técnico, así que no dejeis de echar un vistazo al código de esta "utilidad" :D 

Hay hasta un video en YouTube.

¿Que será lo próximo?

Últimamente me estoy viendo más en la necesidad de usar interfaces y genéricos para crear clases más reusables y tipadas. En mis inicios con C# y .NET... aunque la idea de los genéricos me gustó... a las interfaces ... no les veia demasiada utilidad. A día de hoy soy consciente de la tremenda simbiosis que tienen estos dos elementos para crear código reusable.

Una interfaz, es como la carcasa que envuelve a un dispositivo, la carcasa no tiene funcionalidad en si, pero representa la funcionalidad que que tiene el dispositivo que en ella encaja (pensad en un acople funcional y no físico :P).

Mas...

En Julio apareció en la sección CLR Inside Out del MSDN Magazine un artículo de Shawn Farkas acerca del correcto uso de la interfaz IDisposable (en castellano), explicando el porqué de cada cosa. No puedo explicarlo mejor y más detalladamente de lo que lo ha hecho Shawn Farkas, pero si más resumido

Una de las cuestiones críticas a la hora de optimizar el uso de memoria es que el GC se ejecuta de forma no determinística, esto es, que no podemos predecir cuando se va a realizar, y aunque podemos invocarlo explícitamente con GC.Collect(), no es recomendable.

Mas...

Siguiendo con el artículo anterior donde explicaba que es el código administrado MSIL, voy a explicar ahora también de forma breve como el CLR (Common Language Runtime) ejecuta dicho código con la ayuda del JIT (Just In Time compiler), y cuales son las ventajas y características de este modelo de ejecución. Este es más extenso que el anterior, aunque está todo bastante resumido y explicado por encima espero que resulte interesante. 

Como comentaba, una vez generado el código administrado se compone un ensamblado junto los metadatos, el manifiesto que lo describe y los recursos que se hayan decidido incluir en él, estos datos permiten al CLR obtener información del ensamblado, sus tipos y recuperar el código administrado cuando se requiera.

El CLR es una máquina virtual, un entorno de ejecución para nuestro código MSIL, que provee las siguientes características:

Mas...

Voy a intentar explicar de forma breve en varios artículos como funciona el .NET Framework y que papel juegan sus diferentes partes. En esta primera parte a modo de introducción explicaré la diferencia entre el código fuente y el código administrado generado por el compilador, dejando el CLR y el JIT para una segunda parte.

• El código fuente.

Nuestro código C# (ó cualquier otro lenguaje con el que desarrollemos en .NET... por exótico que sea), es un leguaje de alto nivel con el componemos la lógica que queremos programar.

Aquí se puede ver una extensa lista de los lenguajes con los que se puede programar en .NET.

Bueno, por fin después de varios días trabajando con la versión en desarrollo de BlogEngine.NET para realizar unos cambios y siguiendo los bugs que han ido solventando, tengo las características que necesito como para plantarme e inaugurar el blog !! :D Si alguien ve algún error que me mande un email.

Ahora, http://www.vtortola.net redirecciona aquí siempre.

A partir de ahora bloggearé aquí, e iré recuperando algunos de los artículos que postee en mi antiguo blog en WordPressy mi blog en ElBruno, aunque en este seguiré hanciéndolo.

Ahora gracias al buen soporte para Live Writer, puedo poner código de forma más sencilla que con WordPress y con mejor resultado:

private bool canThreadIt()

{

    bool result = false;

    if (Thread.VolatileRead(ref runThreads) < maxThreads)

    {

        Interlocked.Increment(ref runThreads);

        result = true;

    }

    return result;

}

Pues lo dicho, aquí me encontrareis :D