Opened 16 years ago

Last modified 3 years ago

#30 closed defect

about memory use — at Version 4

Reported by: forgottentowers Owned by: gogo
Priority: lowest Milestone: Version 1.0
Component: Xinha Core Version:
Severity: major Keywords: IE memory leak
Cc: bobesch@…

Description (last modified by gogo)

Hi again!
I used htmlarea, but when I saw xinha I think this is very cool and faster.
I noticed in htmlarea that when I reload a page with the component, the memory was increased in 2mb more, and each refresh that I made add 2mb more to the ie process, I try refreshing the page between six to ten times, and the components hang, maybe when I try two or three times.
Well, that was because I use xinha and saw the same problem, I feel Xinha is more faster, but when I refresh the page the memory doesn??t be purged and only increment the ammount of the ie process.

There are some posts in htmltextarea forum (only if you want to see more information) search "memory leak".

thanks for Xinha ;)
forgottentowers

Change History (4)

comment:1 Changed 16 years ago by Chris Allison

You aren't going to like this answer, but here is some information about this bug. I believe this bug is actually caused by an IE bug with closures. Closures are some type of programming method that can be used in Javascript. I do not know too much about them. However, I believe that Xinha/htmlArea uses them a lot. If you want to read more about them and IE's problem with them, please read the following:

http://www.bazon.net/mishoo/articles.epl?art_id=824

That was written by Mishoo who is the original developer of htmlArea. He does not refer to htmlArea directly about this problem, but it is my opinion that this is probably the same cause of the memory leak in htmlArea.

In summary, I believe the core of Xinha probably uses closures a lot, and it would not be an easy task to remove them. James could probably add more input here, since he probably knows much more about closures than I.

comment:2 Changed 16 years ago by gogo

  • Keywords IE memory leak added
  • Priority changed from high to lowest
  • Severity changed from major to normal

I'm changing this to very low priority, simply because it's probably impossible to fix.

Reading Mish's text, I agree that it is an IE problem where by the garbage collector doesn't handle recursive references correctly. Unfortunatly, removing recursive references would be all but impossible (actually, it probably would be impossible).

Mish's workaround would similarly be impossible to implement.

It's still something we need to keep in mind, but I don't think it can be fixed.

comment:3 Changed 15 years ago by ianb@…

Here's a couple more articles on the problem:

http://jgwebber.blogspot.com/2005/01/dhtml-leaks-like-sieve.html
http://www.quirksmode.org/blog/archives/2005/02/javascript_memo.html

My still-vague impression is that it really kills you when you put Javascript objects (especially things like closures) into the DOM, like in an event handler. This script claims to fix this problem, and would probably be easy to apply:

http://novemberborn.net/javascript/event-cache

comment:4 Changed 15 years ago by gogo

  • Description modified (diff)
  • Priority changed from lowest to highest

Hmmm, that solution looks interesting, I don't know if it would solve all the problem with the IE memory leaks, but certainly it could help. Changing the priority so we can investigate this more (if somebody wants to give it a go, please do, it should be a matter of finding where events are being set and tweaking appropriatly - I can have a look, but might not be soon).

Note: See TracTickets for help on using tickets.