Thursday, January 24, 2008

Performance bajo las líneas

No les ha pasado que luego de cierto tiempo notan que su IE7 comienza a ser un poco mas lento de lo acostumbrado? pues bueno, hace un tiempo descubrí algo similar, la causa, un bicho que no queria salir. Los pasos para el desalojo fueron ciertamente empíricos.
Pero ahora, revisando el blog de Patrick Mackay, he quedado sorprendido por todas las cosas que uno puede hacer con tal de descubrir la causa de un problema. Es asi que podemos partir desde el proceso funcional, buscando llegar incluso a las líneas de código (ojo que estaba hablando del Internet Explorer!)

Patrick comenta algo muy cierto, algo que muchas personas lamentablemente hemos llegado a olvidar:
"A diferencia de una revisión de aplicaciones como asp.net o asp tradicional, donde uno espera encontrar código del cliente que no está optimizado y que consume recursos, en esta oportunidad no había código de terceros. El camino se veía difícil."

He resaltado la parte que quería comentar, pues me he topado en casos en donde, a la pregunta de revisar las fuentes, es incomprensible que tengan en mente soluciones como nuevas alternativas como componentes o tecnologías en boga, cuando muchas veces la raiz se encuentra en el uso indiscrimado de bucles, lecturas o accesos que podrían ser optimizados.

Muchas veces he encontrado respuestas del tipo "pero eso podría ahorrarnos algunos segundos, el problema va por otro lado", bueno, si el problema va por otro lado, pero cual?, llego a pensar.
 
Luego de revisar el código fuente me encuentro con bucles sobre bucles que si bien es cierto, de acuerdo a la teoria, ahora con LINQ pueden reducirse un poco, las soluciones pueden ser tan simples como revisar la lógica asociada y simplicar o elgunos casos extender un poco el código para poder hacer mas liviana la ejecucion de la aplicación.

Creo que el problema ocasionalmente va de la mano con el abuso de recursos, los cuales ultimamente son dados de manera ilimitada. Hace algunos años esuchaba mas terminos como "luchar por cada bit" o "mantenlo en memoria solo cuando lo estes usando", ahora es dificil explicarlo mas aun si es normal ver notebooks de por los menos 2GB de RAM.

En si, tantos recursos disponibles, sea tecnologías en boga o físicos como pcs de elevada potencia, puede que nos nublen un poco, no permitiendo esto enfocarnos correctamente en los aspectos funcionales de nuestra solución.
Esto a la larga puede convertirse en un problema muy serio.

Saludos.

Wednesday, January 16, 2008

VS2008 no soporta ASP Tradicional

Hace poco que me enteré de tal funcionalidad, me parece que esto traera problemas para personas que aun le dan mantenimiento a sistemas basados en ASP, mas aun si es que tenian pensado migrar "por partes" a ASP.NET, la primera opcion a tomar en cuenta será VS2005.
Estaba leyendo que al parecer es una manera de forzar a dejar el lenguaje tradicional, pero creo que no tendría nada de malo que lo siga soportando.

Aquí algunos enlaces:
Dónde esta ASP? http://reddevnews.com/response/response.aspx?rdnid=947
MSDN http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2447716&SiteID=1
MSDN http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2447701&SiteID=1
Mi busqueda en Google http://www.google.com/search?hl=en&newwindow=1&client=firefox-a&rls=org.mozilla:en-US:official&hs=n4Y&sa=X&oi=spell&resnum=0&ct=result&cd=1&q=VS+2008+classic+ASP+support&spell=1

Sin mas, me despido.