Mostrando entradas con la etiqueta programacion. Mostrar todas las entradas
Mostrando entradas con la etiqueta programacion. Mostrar todas las entradas

lunes, 27 de febrero de 2012

jQuery memory leaks in IE 6 and 7

Some years ago, while I was working for Digipro, I was assigned to the development of a control used to display digitalized images using only HTML and javascript. The previous control was developed using ActiveX controls and was having serious difficulties with the increse of security of IE.

Digipro has an application that is used to digitalize images, store them in a database and then query and display them. This application is used by several institutions here in Mexico, most of them banks and finantial institutions.

I started using jQuery for this project, and everything went really smoth and I learnt a lot. But while doing some testing I saw that the memory footprint of IE was growing each time I loaded a new image (about 1 Mb per load). One client noticed it and reported it, but at that time IE 8 went out and they upgraded and everything went fine from there so I never really investigated this bug.

Last week the development manager from Digipro called me because, for some clients, the application became slow and even unresponsive after about and hour using it. It turned out that these clients are still using IE 6 and IE 7 in most of their computers. The manager asked me to debug this component and help them correct this behavior.

I started installing and creating two virtual machines with XP Mode, one with IE 6 and the other with IE 7 to be able to reproduce the bug; and then mounting all the services and application in my development computer.

While using the application I noticed that the developers at Digipro were busy getting a lot of stuff into the component I developed and it have a lot of new functionality. The next thing I noticed was that the memory footprint if IE 7 was growing about 20 Mb each time a new image was loaded and it never went down until I closed the browser. WTF! 20 Mb! When this bug was reported to me (3 years ago) the memory grew less than 1 Mb per image.

After reading a lot of Memory Leaks of javascript in IE
(links:
http://192.168.202.189/IDPortalV9/Wfrm_SB_IntegraMC.aspx?nProyId=3&sUsrID=1139819&sUsrAS=sea&sPlazaID=999&sSucursalID=999&sPerfilID=1502&sAgenciaID=
http://msdn.microsoft.com/en-us/library/ie/bb250448(v=vs.85).aspx
http://stackoverflow.com/questions/1261244/how-to-use-ie7-javascript-memory-leak-detectors
http://home.wanadoo.nl/jsrosman/sievehelp.htm
http://blogs.msdn.com/b/ie/archive/2007/11/29/tools-for-detecting-memory-leaks.aspx
http://javascript.crockford.com/memory/leak.html
http://www.codeproject.com/Articles/12231/Memory-Leakage-in-Internet-Explorer-revisited
http://www.javascriptkit.com/javatutors/closuresleak/index.shtml
)

I realized that I needed a tool to help me find them. So I downloaded DripsIEve, and IEJsLeaksDetector. All of them great applications.

The tools reported several leeks each time an image was unloaded and a new one was loaded. This step does a postback to the server and all controls of the page are re-created.



I was shocked to see that most of the leeks where related to jQuery functions. I was expecting to find some really nasty and obvious bugs in the code of the component.
So I started to unbind every event of every object I found. And the memory footprint started going down until it reached about 5 Mb per image. At that point, the only leaks that sIEve was reporting where related to the jQuery UI draggable plugin and I was having a hard time trying to remove them. So in a moment of despair I tried to select all objects and unbind all events from them.



I was really shocked to find out that sIEve was still reporting the same leaks, and more over, IEJSLeaksDetector was showing that the window object hasn't been disposed. And the memory kept growing about 4 Mb after each image load.




So I started looking on the web for this strange behavior and found several reports of it. Two of them where bug reports in the jQuery Bug Tracker. Tickets 6421 and 8863. The first one of them had a proposed solution and after implementing it, the leaks were gone.



So, after this weekend that almost was a nightmare I have decided to bill a lot more each time an application have to support IE 6 or IE 7.

martes, 5 de octubre de 2010

Cuentas restringidas en AspNet

Siempre me ha dado cosa ver que se usan usuarios con todos los privilegios en las aplicaciones de ASP .Net en las que he trabajado. Todas menos una y con la cual aprendí que se podían restringir los permisos del usuario con el que trabaja la aplicación, o mejor aún, cambiarlo por uno especifíco que tenga ya los permisos que queremos.

En esa empresa se usaba un documento que no se de donde obtuvieron y que no he vuelto a ver por ningún lado, el cual se llamaba SecNet.pdf

La parte que indicaba cuales eran los permisos mínimos que necesitaba una cuenta para ejecutar una aplicación de Asp.Net la acabo de encontrar en esta liga.http://msdn.microsoft.com/en-us/library/Aa508562.

Once and again, básicamente para que no se me olvide.

miércoles, 19 de mayo de 2010

PageMethods y [WebMethod]

El día de hoy aprendí sobre los PageMethods:

Aunque yo haría la validación en Javascript en lugar de dejar que el servidor la haga (aún cuando la información enviada es poca):
http://www.singingeels.com/Articles/Using_Page_Methods_in_ASPNET_AJAX.aspx

Explicando porque es malo usar los Update Panels... la parte más interesante es la del viewstate... siempre viaja con los update panels, por lo que si en tu vida te has preocupado por cuidar tu viewstate (como los desarrolladores de cierta aplicación con la cual estuve trabajando hasta hace poco), de nada servirá "usar Ajax" porque es casi como si mandaras tu página completa. En fin... mejor no hago berrinche
http://blogs.msdn.com/b/davidsalgado/archive/2008/05/05/asp-net-ajax-updatepanel-vs-asp-net-pagemethod.aspx

Y pues, el Script Manager siempre se me ha hecho demasiado grande y pesado, por lo que la idea de no usarlo es genial:
http://geeks.ms/blogs/jmaguilar/archive/2008/06/02/acceder-a-pagemethods-con-jquery.aspx

http://encosia.com/2008/05/29/using-jquery-to-directly-call-aspnet-ajax-page-methods/

Debo admitir que es algo que empezaré a usar siempre que alguien más ya haya referenciado el .Net Ajax Framework, pero no es algo que yo metería a una aplicación desde 0. Prefiero usar el ajax a patita, cual vil cavernicola:

Cavernicola

Pero bueno, una vez más, los links aquí guardados por si a alguien más le interesan y para acordarme con eso de que el Alzhaimer está cada día peor... :S

lunes, 14 de septiembre de 2009

SlimCode

Acabo de cambiar mis estilos de mi Visual Studio... lo cambie por este:

SlimCode

(Ya se que a nadie le interesa como se ve mi VS, este link es más que nada para acordarme de donde lo saqué... =p)

martes, 8 de septiembre de 2009

¿Pa' qué LNKarel?

Dado que es posible que varios se pregunten ¿pa' que LNKarel?, adelanto la respuesta y de paso espero poder responder a Dueñez.

La idea del LNKarel es la misma que tuve hace algún tiempo de hacer un Karel "Visual"; esto es, que el programa que ejecutará Karel no se escriba en la sintaxis de algún lenguaje (Java o Pascal en el caso del OMIKarel, y Java en el caso del Karel Arena que está desarrollando la OIEG), sino que se construya con bloques fácilmente identificables. De esta manera (al igual que el LKarel que hice para Marroquín hace algunos años) no existirá parser (al menos no en código porque según Dueñez el parser es el mismo usuario).

La justificación de esto es algo que considero todavía debatible.

Considero que el escribir con una sintaxis correcta en un lenguaje formal es una habilidad necesaria en todo programador, no solo porque tienes que escribir correctamente en algún lenguaje de programación (que es un lenguaje formal), sino porque el resto de las habilidades necesarias para programar se desarrollan a la par del aprendizaje del lenguaje.

Dicho lo anterior, ¿por qué quiero quitarle eso a Karel?








Realmente, mi objetivo es proporcionarle un "lenguaje" a niños que aún no tienen las habilidades de escritura completamente desarrolladas (lo cual probablemente en México incluya a gente que ya está en licenciatura). El público final (esperado) son niños entre 6 y 10 años.

martes, 30 de junio de 2009

Android

El día de hoy me enteré de que existe Android

A veces me da miedo Google... Como sea lo prefiero a Microshit

miércoles, 24 de junio de 2009

Secciones de configuración

Se me había olvidado postear sobre las secciones de configuración.

Encontré un error que, al menos por google, parece ser bastante común y no es clara en casi ningun foro ni nada la solución que encontré.

.Net Connection Pool

El dia de hoy aprendí sobre la connection pool de .net