[jquery] Jquery memory leak patterns

[Rekcor]

Klopt het dat dit een memory leak oplevert?

JavaScript:

myobject = function() {
  this.name = 'my object';
}

myobject.prototype.myFunction = function() {
 var myObject = this;
 jQuery('#myDiv').click(function(){
   var name = myObject.name;
   this.html(name);
 });
}

In 'myFunction' maak ik namelijk een verwijzing naar 'myObject', waaraan ik vervolgens refereer in de click-closurefunctie.

Zo ja, klopt het dan ook dat het volgende wel goed gaat?

JavaScript:

myobject = function() {
  this.name = 'my object';
}

myobject.prototype.myFunction = function() {
 jQuery('#myDiv').data('myObject', this);

 jQuery('#myDiv').click(function(){
   var myObject = jQuery(this).data('myObject');

   jQuery(this).html(myObject.name);
 });
}

Ik meen ergens gelezen te hebben dat het zo goed gaat, omdat jQuery alle referenties die met .data gemaakt zijn, kan wissen. Maar ik kan het betreffende artikel niet meer terugvinden...

Memory leaks geven me

[ Voor 2% gewijzigd door Rekcor op 08-11-2011 15:09 . Reden: foutje + eerste voorbeeld niet goed ]

[Grijze Vos]

Ik ben geen JS guru, maar is het niet handiger om (als je met jQ werkt) jQuery widgets te schrijven ipv prototypes schrijven?

[Rekcor]

Misschien, maar het ging me om het voorbeeld: het refereren naar een object in een closure, en vervolgens dat doen via Jq data.

[Miyamoto]

Kun je dat niet makkelijk testen door een dergelijke sequence vaak genoeg uit te voeren en naar het geheugengebruik van de browser te kijken?

De onderliggende vraag is dat je een memory leak hebt, maar niet weet waar deze vandaan komt?

[NetForce1]

Rekcor schreef op maandag 07 november 2011 @ 15:01:
Klopt het dat dit een memory leak oplevert?

JavaScript:

myobject = function() {
  this.name = 'my object';
}

myobject.prototype.myFunction = function() {
 var myObject = this;
 jQuery('#myDiv').click(function(){
   this.html(myObject.name);
 });
}

In 'myFunction' maak ik namelijk een verwijzing naar 'myObject', waaraan ik vervolgens refereer in de click-closure.

Zo ja, klopt het dan ook dat het volgende wel goed gaat?

JavaScript:

myobject = function() {
  this.name = 'my object';
}

myobject.prototype.myFunction = function() {
 jQuery('#myDiv').data('myObject', this);

 jQuery('#myDiv').click(function(){
   var myObject = jQuery(this).data('myObject');

   jQuery(this).html(myObject.name);
 });
}

Ik meen ergens gelezen te hebben dat het zo goed gaat, omdat jQuery alle referenties die met .data gemaakt zijn, kan wissen. Maar ik kan het betreffende artikel niet meer terugvinden...

Memory leaks geven me

Event listeners die je met jQuery registreerd worden ook in data opgeslagen, dus die worden ook gewist. Je eerste voorbeeld lijkt me dan ook niet te leaken op het eerste gezicht. Overigens moet je dan wel jQuery gebruiken om het element uit je DOM te halen, anders kan jQuery ook niet weten dat er iets uit de data-store moet.

[Rekcor]

Miyamoto schreef op maandag 07 november 2011 @ 18:55:
Kun je dat niet makkelijk testen door een dergelijke sequence vaak genoeg uit te voeren en naar het geheugengebruik van de browser te kijken?

Ik geloof niet zo in testen, zeker niet als het complexe (web)applicaties betreft. Het is beter om naar je code te kijken, om lekken te voorkomen.

Ik weet dus niet of ik een lek heb, maar wil graag voorkomen dat er lekken komen

[Bosmonster]

jQuery wist niet uit zichzelf user-set data. Het hele idee daarvan is juist dat het behouden blijft en je de optie geeft data te koppelen aan de dom.

Maar data gaan misbruiken als een soort closure is wel redelijk ranzig.

[NetForce1]

Bosmonster schreef op dinsdag 08 november 2011 @ 08:28:
jQuery wist niet uit zichzelf user-set data. Het hele idee daarvan is juist dat het behouden blijft en je de optie geeft data te koppelen aan de dom.

Niet helemaal uit zichzelf, maar wel als je bijv. .empty() aanroept op een element, dan worden van de descendents daarvan de data gewist.

[Bosmonster]

Maar dan bestaan die nodes ook niet meer

In het voorbeeld van TS wordt de data (gelukkig) niet automatisch zomaar verwijderd.

[ Voor 50% gewijzigd door Bosmonster op 08-11-2011 10:27 ]

[Rekcor]

Bosmonster schreef op dinsdag 08 november 2011 @ 10:25:
Maar dan bestaan die nodes ook niet meer

In het voorbeeld van TS wordt de data (gelukkig) niet automatisch zomaar verwijderd.

Maar, leidt het voorbeeld van TS (en dan met name het bovenste voorbeeld) ook tot memory leaks?

En waarom is de .data-optie ranzig?

[Bosmonster]

Waarom denk je dat het tot memory leaks zou leiden? Wat is je onderbouwing?

De tweede optie is niet per definitie ranzig (eigenlijk is het best prima op de manier waarop je het nu doet). Wat wel ranzig is is om data gebruiken als vervanging voor closures (en dat zie ik helaas nog wel eens voorkomen).

Je doet in feite wel hetzelfde, maar met een betere bedoeling, namelijk je interne object koppelen aan je dom-node. En dat is een prima doel.

Waar je dan wel op moet letten is dat je die koppeling ook weer ongedaan maakt als je je interne object verwijdert. Een destructor dus die je data ook weer cleart.

[ Voor 34% gewijzigd door Bosmonster op 08-11-2011 10:35 ]

[crisp]

Wat versta je precies onder een 'memory leak'? Het lijkt me dat de garbage collection de referentie prima kan opruimen zodra het element zelf wordt verwijderd of de eventlistener wordt verwijderd. Referenties naar JS objecten opslaan in de DOM leidt in IE (<=7) iig wel tot memoryleaks.

[Rekcor]

JavaScript:

myobject = function() {
  this.name = 'my object';
}

myobject.prototype.myFunction = function() {
 var myObject = this;
 jQuery('#myDiv').click(function(){
   var name = myObject.name;
   this.html(name);
 });
}

Maar als ik '#myDiv' verwijder uit de DOM (dmv jQuery('#myDiv').remove()), dan kan de garbage collector hem toch niet opruimen, aangezien myObject dan nog bestaat?

In het tweede voorbeeld kan garbage collector wel de '#myDiv' opruimen, want je mag aannemen dat jQuery alle variabelen in ".data" op null zet...

[ Voor 3% gewijzigd door Rekcor op 08-11-2011 15:09 . Reden: voorbeeld niet goed ]

[NetForce1]

Rekcor schreef op dinsdag 08 november 2011 @ 15:08:

JavaScript:

myobject = function() {
  this.name = 'my object';
}

myobject.prototype.myFunction = function() {
 var myObject = this;
 jQuery('#myDiv').click(function(){
   var name = myObject.name;
   this.html(name);
 });
}

Maar als ik '#myDiv' verwijder uit de DOM (dmv jQuery('#myDiv').remove()), dan kan de garbage collector hem toch niet opruimen, aangezien myObject dan nog bestaat?

In het tweede voorbeeld kan garbage collector wel de '#myDiv' opruimen, want je mag aannemen dat jQuery alle variabelen in ".data" op null zet...

myDiv kan wel opgeruimt worden volgens mij, want myObject heeft geen referentie naar myDiv.

[JohnStaakke]

NetForce1 schreef op dinsdag 08 november 2011 @ 15:16:
[...]

myDiv kan wel opgeruimt worden volgens mij, want myObject heeft geen referentie naar myDiv.

Volgens mij ook.

[R4gnax]

crisp schreef op dinsdag 08 november 2011 @ 10:36:
Wat versta je precies onder een 'memory leak'? Het lijkt me dat de garbage collection de referentie prima kan opruimen zodra het element zelf wordt verwijderd of de eventlistener wordt verwijderd. Referenties naar JS objecten opslaan in de DOM leidt in IE (<=7) iig wel tot memoryleaks.

Dit is inderdaad de kern v/h verhaal. Dat is waarom jQuery aan DOM nodes een GUID toekent en deze vervolgens als index gebruikt om data behorende bij nodes in een van de DOM vrijstaande store te manipuleren.

Omdat ook event handlers op deze manier bewaard worden kan er nooit een circulaire referentie ontstaan. Dit wil zeggen dat hoe dan ook de garbage collector zijn werk kan doen om geheugen behorende bij DOM nodes op te ruimen. Er kan dan hoogstens wat rommel in de vrijstaande data store achterblijven, maar die wordt als ik me goed herinner gepruned.

Rekcor schreef op dinsdag 08 november 2011 @ 10:28:
[...]

Maar, leidt het voorbeeld van TS (en dan met name het bovenste voorbeeld) ook tot memory leaks?

En waarom is de .data-optie ranzig?

Nee, het bovenste voorbeeld leidt om bovenstaande redenen niet tot een (permanente) memory leak.

Verder is de .data-optie ranzig omdat er veel betere opties zijn om dit scenario af te handelen. $.fn.data is een constructie waarmee je snel ongestructureerde rommel kunt krijgen als je het te pas en te onpas gebruikt.

Als je echt data aan een handler mee wilt geven, dan doe je dat m.b.v. event.data. Verder is het trouwens beter voor de leesbaarheid van je code om niet allemaal handlers 'inline' te schrijven, maar ze als methods op je prototype te zetten en via jQuery.proxy de context juist te zetten. EN je kunt je prototype zelf ook een stuk leesbaarder noteren :

JavaScript:

window.MyObject = function() {
  var me = this;

  me.name = 'my object';
}

window.MyObject.prototype = {
 /**
  * Initializes a new instance of MyObject
  */
 constructor : window.MyObject,

 /**
  * Does some work ...
  */
 myFunction : function() {
   var me = this, elem;
 
    elem = jQuery( "#myDiv" );
    elem.bind( "click", el, jQuery.proxy( me._myClickHandler, me ));
  }

  /**
   * @private
   * Handles click events on the associated DOM element.
   * @param {jQuery.Event} An event object, normalized by jQuery.
   */
  _myClickHandler : function( event ) {
    var me = this, elem = event.data;
  
    elem.html( me.name );
  }
};

(Strikt genomen is het doorgeven v/h element in dit soort situaties trouwens niet eens nodig. Je zou namelijk event.currentTarget moeten kunnen gebruiken.)

Grijze Vos schreef op maandag 07 november 2011 @ 15:51:
Ik ben geen JS guru, maar is het niet handiger om (als je met jQ werkt) jQuery widgets te schrijven ipv prototypes schrijven?

Eigenlijk is $.widget een class factory die ook prototypes aanmaakt, maar het schrijft (en nog belangrijker: leest!) inderdaad vele malen makkelijker. Ik zou alleen willen dat er een degelijke manier was om namespaces te gebruiken zodat $.fn niet vervuilt raakt met allerlei extra functies en dat de factory niet zo sterk verwoven was met $.Widget, maar ook gebruikt kon worden voor classes in het algemeen. (Daarvoor gebruik ik nu een eigen geschreven class factory.)

[ Voor 0% gewijzigd door R4gnax op 14-11-2011 21:45 . Reden: Bug in voorbeeld code ]

[Rekcor]

Bedankt voor jullie reacties! Ik leer een hoop bij!

[_Thanatos_]

Ik mag toch aannemen dat dit afhankelijk is van een bepaalde javascript engine.

Je mag toch verwachten dat hedendaagse javascript engines wel in staat zijn om geheugenlekken niet meer te veroorzaken. In javascript ben je nml helemaal niet bezig met het alloceren en vrijgeven van blokken geheugen, zoals je deed in een 3G-programmeertaal. Javascript is een hogere taal die draait in een sandbox/VM waarvan de host verantwoordelijk is voor het alloceren en vrijgeven van geheugen. AL het geheugen dat je in javascript "alloceert" wordt beheert door de engine, en het is dan dus aan de engine om te weten wanneer objecten niet langer gerefereerd worden en vrijgegeven kunnen worden.

Je kunt natuurlijk wel constructies verzinnen die ervoor zorgen dat een object tot de eerstvolgende reload gebruikt wordt, maar dat is geen geheugenlek. Dat is geheugengebruik.

Gewoon nette code schrijven dus. JSLint laten valideren ook vooral. En zorgen dat er geen errors in je code zitten, ook geen errors die javascript toch stiekem tolereert.

deze reactie is natuurlijk te verwachten in een topic als dit heh