Hi, According to this blog post http://clientside.cnet.com/?p=114 a way to fix memory leak is to NEVER store DOM element in the "this" object but otherwise use the object id and call $(id) all the time. For my own project i didn''t do that, in fact I store DOM element then on unload set it to null. It seems to work ? But I am asking two question: 1. Is $() using in this way is time consuming ? 2. When working with DOM elements retrieved from $ or $$ or what ever... the elements might not have id. In fact, in an HTML page only few elements have an id. So what should I do ? Is there a magic function to create a new unique Id ? Best Regards, Jp -- Jean-Philippe Encausse - R&D Jalios SA Jp [at] encausse.net - http://www.encausse.com - http://www.jalias.com GTalk: jp.encausse [at] gmail.com - SMS: sms [at] jp.encausse.net Mob: +33682125699 - Job: +33139239283 - Tel: +33139189015 - Fax: +33958789015 Do it Once, Use it Twice ~ Do it Twice, Make It Once --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
Interesting. I frequently have stored a reference to a DOM element and
not seen a major problem. I wonder if the article is a little bit on
the FUD side of an argument.
Regardless, if you use $ or $$ to get back references to an object, you
could set a property to those references which will persist for as long
as the object does. Thus:
$$("ul#menu li").each(function(element) { element.myId =
Math.random(); });
Would set a javascript property to your elements with a random (and thus
somewhat unique) value. You couldn''t use that value, however, to get
back at that reference later, though. You could do something like this,
though:
$$("ul#menu li").each(function(element) {
element.setAttribute("id",
"item_"+Math.random()) });
That should set the actual id attribute of each element to "item_###"
where ### is a random number from Math.random(). You could then also
store those random IDs and use them to get back at the elements using
$() at a later date. But, as I said at the top, I''ve stored references
to DOM elements without seeing much of a problem. Hell, using the above
two lines of code, we have a DOM object reference in the form of
"element," so a modicum of such variables is probably unavoidable.
- Dash -
Jean-Philippe Encausse wrote:> Hi,
>
> According to this blog post http://clientside.cnet.com/?p=114 a way to
> fix memory leak is to NEVER store DOM element in the "this"
object but
> otherwise use the object id and call $(id) all the time.
>
> For my own project i didn''t do that, in fact I store DOM element
then
> on unload set it to null. It seems to work ?
>
> But I am asking two question:
>
> 1. Is $() using in this way is time consuming ?
>
> 2. When working with DOM elements retrieved from $ or $$ or what
> ever... the elements might not have id. In fact, in an HTML page only
> few elements have an id. So what should I do ? Is there a magic
> function to create a new unique Id ?
>
> Best Regards,
> Jp
>
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---
Thanks,
The leak append when an object of the JS world store an object of the
DOM world in IE 6 only. Because of GC problems.
http://www.codeproject.com/jscript/leakpatterns.asp
About your code I would do
$$("ul#menu li").each(function(element,idx) { element.myId
Math.random()+idx; });
I would add "idx" because Math.random() is based on current system
time. On fast computer you will have the same result because opertaion
are done at the same millisec.
Or I would do Math.random(idx) to use an other seed
Does anybody know a good JavaScript/IE memory leak finder ? I use Drip
0.5 that should be the best but not very user friendly...
Regards
On 6/11/07, David Dashifen Kees
<dashifen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:>
> Interesting. I frequently have stored a reference to a DOM element and
> not seen a major problem. I wonder if the article is a little bit on
> the FUD side of an argument.
>
> Regardless, if you use $ or $$ to get back references to an object, you
> could set a property to those references which will persist for as long
> as the object does. Thus:
>
> $$("ul#menu li").each(function(element) { element.myId >
Math.random(); });
>
> Would set a javascript property to your elements with a random (and thus
> somewhat unique) value. You couldn''t use that value, however, to
get
> back at that reference later, though. You could do something like this,
> though:
>
> $$("ul#menu li").each(function(element) {
element.setAttribute("id",
> "item_"+Math.random()) });
>
> That should set the actual id attribute of each element to
"item_###"
> where ### is a random number from Math.random(). You could then also
> store those random IDs and use them to get back at the elements using
> $() at a later date. But, as I said at the top, I''ve stored
references
> to DOM elements without seeing much of a problem. Hell, using the above
> two lines of code, we have a DOM object reference in the form of
> "element," so a modicum of such variables is probably
unavoidable.
>
> - Dash -
>
> Jean-Philippe Encausse wrote:
> > Hi,
> >
> > According to this blog post http://clientside.cnet.com/?p=114 a way to
> > fix memory leak is to NEVER store DOM element in the "this"
object but
> > otherwise use the object id and call $(id) all the time.
> >
> > For my own project i didn''t do that, in fact I store DOM
element then
> > on unload set it to null. It seems to work ?
> >
> > But I am asking two question:
> >
> > 1. Is $() using in this way is time consuming ?
> >
> > 2. When working with DOM elements retrieved from $ or $$ or what
> > ever... the elements might not have id. In fact, in an HTML page only
> > few elements have an id. So what should I do ? Is there a magic
> > function to create a new unique Id ?
> >
> > Best Regards,
> > Jp
> >
> >
>
> >
>
--
Jean-Philippe Encausse - R&D Jalios SA
Jp [at] encausse.net - http://www.encausse.com - http://www.jalias.com
GTalk: jp.encausse [at] gmail.com - SMS: sms [at] jp.encausse.net
Mob: +33682125699 - Job: +33139239283 - Tel: +33139189015 - Fax: +33958789015
Do it Once, Use it Twice ~ Do it Twice, Make It Once
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---
On Jun 12, 3:16 pm, "Jean-Philippe Encausse" <J...-vcK5r0oTKUrk1uMJSBkQmQ@public.gmane.org> wrote:> Thanks, > > The leak append when an object of the JS world store an object of the > DOM world in IE 6 only. Because of GC problems.Problems with IE memory leaks (which probably should be called JScript memory leaks, not javascript leaks) can be fixed by removing handlers involving cicular references with DOM and window objects in intrinsic event handlers. <URL: http://www.jibbering.com/faq/faq_notes/closures.html#clMem >> http://www.codeproject.com/jscript/leakpatterns.asp > > About your code I would do > > $$("ul#menu li").each(function(element,idx) { element.myId > Math.random()+idx; }); > > I would add "idx" because Math.random() is based on current system > time. On fast computer you will have the same result because opertaion > are done at the same millisec.I seriously doubt that - there is nothing in the ECMAScript specification that says how Math.random works. Most modern computers can calculate quite a few random numbers per millisecond - a 2GHz Core2Duo does between 10 and 50 in Firefox, up to 170 in Safari. A simple test shows no duplicates in all the numbers generated in a single millisecond. Do you have any references indicating a problem? The ECMAScript spec says: "15.8.2.14 random ( ) "Returns a number value with positive sign, greater than or equal to 0 but lessthan 1, chosen randomly or pseudo randomly with approximately uniform distribution over that range, using an implementation-dependent algorithm or strategy. This function takes no arguments." I don''t see anywhere there that says "must use the system clock to seed the algorithm". -- Rob --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
> I seriously doubt that - there is nothing in the ECMAScript > specification that says how Math.random works. Most modern computers > can calculate quite a few random numbers per millisecond - a 2GHz > Core2Duo does between 10 and 50 in Firefox, up to 170 in Safari. A > simple test shows no duplicates in all the numbers generated in a > single millisecond. Do you have any references indicating a problem? > > The ECMAScript spec says: > > "15.8.2.14 random ( ) > "Returns a number value with positive sign, greater than or > equal to 0 but lessthan 1, chosen randomly or pseudo > randomly with approximately uniform distribution over that > range, using an implementation-dependent algorithm or > strategy. This function takes no arguments." > > I don''t see anywhere there that says "must use the system clock to > seed the algorithm". >In fact I already get this issue in Java so I thought it could be possible in JavaScript. -- Jean-Philippe Encausse - R&D Jalios SA Jp [at] encausse.net - http://www.encausse.com - http://www.jalias.com GTalk: jp.encausse [at] gmail.com - SMS: sms [at] jp.encausse.net Mob: +33682125699 - Job: +33139239283 - Tel: +33139189015 - Fax: +33958789015 Do it Once, Use it Twice ~ Do it Twice, Make It Once --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---