Hace unos VisionConsulting mi pidió de favor que les echara la mano con una auditoría que IBM les consiguió para el SAT (después de lo que hice en Monterrey con MS, ¿se acuerdan?). Desgraciadamente y por otros compromisos no tuve oportunidad de apoyarlas y hace unos días el director general me invitó a comer para que le diera una plática al recurso que enviaron sobre performance y auditoría de las aplicaciones desarrolladas en .NET
Vimos varios detalles, pero un proceso de auditoría no es un «corre un FXCop» y reporta los resultados. Un proceso de auditoría es un proceso iterativo en el que se requieren hacer muchos pasos y ciertos lineamientos y es algo complicado, que tiene que ir de lo general a lo puntual y lo caracteristico.
Tomemos un ejemplo: las operaciones de cadena. En .NET se provee un tipo de dato que se llama System.String que nos permite representar a una cadena de caracteres. Muchos aplicaciones utilizan el String no adecuadamente, y una manipulación intensiva de cadenas puede afectar significativamente el rendimiento de la aplicación… ¿Porqué? por la naturaleza inmutable del tipo. Esto significa que siempre que hacemos una operación dentro de una cadena, la cadena original esta enviada al GC y una nueva es creada para guardar los nuevos datos (¡dos variables!) además de que los tipos de System.String son guardados como referencia (apuntador) a un lugar en memoria.
Tomemos este ejemplo:
| 1 | foreach(Field f in Table.Fields) |
| 2 | { |
| 3 | sql += «where » + field.Name + » = » + field.Value; |
| 4 | } |
Aquí estamos creando una cadena nueva en cada paso que se esta enviando al GC … yikes!
Dentro de .NET, existe un objeto que se llama StringBuilder, el cual nos permite guardar cadenas dentro de una colección (muy a la manera que elementos dentro de una lista) y finalmente nos regresa toda la cadena pidiendole el nombre de la clase.ToString()
| 1 | StringBuilder sb = new StringBuilder(); |
| 2 | foreach(Field f in Table.Fields) |
| 3 | { |
| 4 | sb.Append(String.Format(«where {0} = {1}», f.Name, f.Value)); |
| 5 | } |
Nota en el ejemplo anterior que tambien estamos usando String.Format en vez de concatenar la cadena. Es mejor que concatenar ya que va a reemplazar los StringPlaceholders por los valores enviados.
Esta es la forma recomendada de concatenar cadenas mientras desarrollamos aplicaciones. Es un punto muy sencillo, pero muchas, muchas veces está pasado por alto. ¿Por qué lo comento en este post? el código que ví hacían concatenaciones ENORMES de XML que, tal vez cuando un usuario esta trabajando no afectan el rendimiento… pero que tan cuando son 1,500 usuarios concurrentes con 1GB de datos… la cosa cambia… ¿no?
Cheers!
Deja una respuesta
Lo siento, debes estar conectado para publicar un comentario.