Wann ist $ .cache zu groß?

Ich habe vor kurzem in this tutorial gelesen, dass bestimmte jQuery Lecks durch die Variable $.cache verfolgbar sind, und Sie sollten immer seine Größe überprüfen, wenn es zu groß ist, tun Sie etwas falsch.

Nun, wie groß ist zu groß? Gibt es eine Möglichkeit, eine Variable zu überprüfen, um zu sehen, wie viel Speicher sie verbraucht?

Ich arbeite an einer Website, die 210 Objekte nur durch Laden der Homepage speichert. Ist, dass zu viel? Ich würde mich über eine gründliche Erläuterung des Problems hier freuen.

Quelle

2012-10-10 ChuckE

Es geht nicht darum, wie groß es ist, sondern wie es wächst im Laufe der Zeit. Wenn der Cache nicht begrenzt ist (d. H. Für immer zunimmt), haben Sie wahrscheinlich ein Speicherleck. –

jQuery ist wirklich Browser-kompatibel. Es bringt das IE-Problem mit sich, Elemente in allen Browsern richtig zu entsorgen. –

Sie würden hart gedrängt werden, moderne Gedächtnisfähigkeiten zu belasten, wenn Sie vernünftig sind. Es sei denn, Sie erstellen ein Speicherleck, das groß genug ist. Es gibt keinen magischen Speicher, alles hängt von der Hardware eines Benutzers ab. Interessieren Sie sich für Leute, die Computer aus den 90er Jahren benutzen? –

$.cache 's Größe bei Nennwert sagt nichts über Speicherverluste. Es könnte sehr klein sein und immer noch ein Speicherleck haben, oder es könnte sehr groß sein und keinen Speicherleck haben.

Wenn Sie wissen, dass Sie 10 Ereignis-Listener mit jQuery auf der Seite zu einer Zeit gebunden haben, und noch $.cache Einträge für mehr hat, dann wissen Sie, dass Sie undicht sind.

Ein großer Speichersparmodus besteht darin, die Ereignisdelegierung zu verwenden, anstatt Event-Listener an jedes einzelne Element anzuhängen.

Sprich:

<ul> 
    <li></li> 
    <li></li> 
    <li></li> 
</ul>

$("li").on("click", fn) würde befestigen 3 individuelle Event-Handler (mehr, wenn Sie mehr li natürlich haben), während $("ul").on("click", "li", fn) befestigen würde man nur unabhängig davon, wie viele li-Elemente, die Sie haben und noch haben das gleiche Ergebnis.

Beispiel Leck:

$("button").click(function() { 
    $("#target")[0].innerHTML = ""; 
    $("<div>").appendTo($("#target")).click($.noop); 
    $("#log").text(Object.keys($.cache).length); 
});

http://jsfiddle.net/SGZW4/1/

Grund dafür ist, dass .innerHTML verwendet, die nicht Teil von jQuery ist, so dass es aufzuräumen nicht tun kann.

Fix ist jQuery-Methode für das gleiche zu verwenden:

$("button").click(function() { 
    $("#target").html(""); 
    $("<div>").appendTo($("#target")).click($.noop); 
    $("#log").text(Object.keys($.cache).length); 
});

http://jsfiddle.net/SGZW4/2/

Quelle

2012-10-10 12:50:57 Esailija

das ist ein guter Tipp. Aber wie kann ich die Variable $ .cache verwenden, um meine Speicherbelegung besser zu überprüfen? Ein Beispiel, an das ich gerade dachte: Überprüfen Sie die Anzahl der zwischengespeicherten Elemente, klicken Sie auf eine Schaltfläche und haben Sie ein erwartetes visuelles Verhalten, überprüfen Sie die Anzahl der zwischengespeicherten Elemente, klicken Sie auf die Schaltfläche, die die vorherige Aktion "zurücksetzt", und sehen Sie, ob die zwischengespeicherte Elementnummer ist die gleiche wie zu Beginn dieses Tests. Ist das zum Beispiel eine gute Verwendung des $ .cache, um die Speichernutzung zu testen? – ChuckE

@ChuckE Ich würde mir keine Gedanken über $ .cache machen. Eine Möglichkeit, die ganze Sache zu vermeiden, besteht darin, die Ereignisdelegierung ausschließlich für statische Elemente zu verwenden, die niemals an erster Stelle entfernt werden. Ansonsten stellen Sie sicher, dass Sie immer jQuery-Methoden verwenden und nicht die Standard-DOM-Methoden: http://jsfiddle.net/SGZW4/1/ vs http://jsfiddle.net/SGZW4/2/ – Esailija

humm, interessant. Das bedeutet, dass $ .cache für den getesteten Fall nicht einmal prüfen kann, ob ein Speicherleck vorliegt. – ChuckE

Antwort

Verwandte Themen