Speicherverbrauch

[Chris M.]

Da die CometVisu eine lang laufende Web Seite, äh, Applikation, ist, macht es viel Sinn die bzgl. Speicherverbrauch zu optimieren und v.a. jegliche Leaks zu stoppen.

Zum Glück bietet der Chrome ja ein paar Nette Möglichkeiten dafür (die ich teilweise nicht mal im Ansatz kapiere... )
=> Hier kann jeder andere auch sehr gut helfen!

Was ich aber bei leerer Config meine gefunden zu habe, ist dass der CometVisu-Client Watchdog Date()-Objekte leakt. Wenn ich den ändere zu:

  var watchdog = (function(){
    var last = new Date();
    var hardLast = last;
    var aliveCheckFunction = function(){
      var now = new Date();
      if( now - last < thisCometVisu.maxConnectionAge * 1000 ) return;
      if( now - hardLast > thisCometVisu.maxDataAge * 1000 ) thisCometVisu.lastIndex = -1; // reload all data
      thisCometVisu.restart();
      last = now;
    };
    var aliveHandler = setInterval( aliveCheckFunction, thisCometVisu.watchdogTimer * 1000 );
    return {
      ping: function(){
        [B]delete last;[/B]
        last = new Date();
        if( !thisCometVisu.doRestart )
        {
          [B]delete hardLast;[/B]
          hardLast = last;
        }
      }
    };
  })();

wird's deutlich besser.

Aber wieso?!?
Hier hatte ich auf die GC vertraut, schließlich wird das alte Date-Objekt ja durch die neue Zuweisung herrenlos und sollte dann von selbst gelöscht werden...

[Chris M.]

Mit dem Raten der Ursachen bin ich noch nicht wirklich weiter - aber habe eine Spur, dass das Diagram-Plugin wohl bei den Updates leakt.

Also nochmal der Aufruf: Wenn jemand halbwegs eine Idee hat, wie man die Tools verwendet um im JavaScript Leaks zu finden, bitte gerne mal loslegen! (Ich bin da wohl zu doof dazu, das effektiv hin zu bekommen...)
Auch wenn kein oder nur kaum Verständnis über die internen Strukturen der CV vorhanden sind - dann lösen wir's halt zusammen

[tht]

Hi Chris,

Ich bin zwar wahrlich kein JS-Experte, aber nach kurzem überfliegen von How to write low garbage real-time Javascript glaube ich für den Watchdog folgendes verstanden zu haben:

In der bisherigen Implementierung erzeugt jeder Ping eine neue Funktion, die dann wohl auch jedes Mal die Variablen neu enthält. Dadurch wird auch jedes Mal der notwendige Speicher allokiert.

Die saubere Lösung wäre laut dem Artikel die Funktion statt inline schon beim startup zu initialisieren und dann nur noch aufzurufen, wobei die Funktion dafür ggf. wohl angepasst werden müsste...

Ansonsten läuft - soweit ich den Artikel verstanden habe - die GC quasi nach Lust und Laune des Browsers.

Wie gesagt: JS ist mir nicht fremd, aber ich bin wahrlich kein Experte und kann auch keine Gewähr für den Artikel oder meine Interpretationen übernehmen, hoffe aber geholfen zu haben.

[eutelli]

  
      ping: function(){
        [I]//[B]delete last;[/B][/I]
        [B]last = null;[/B]

        last = new Date();
        if( !thisCometVisu.doRestart )
        {
          [I][B]//delete hardLast;[/B][/I]
          [B]hardLast = null;
[/B]           hardLast = last;
        }
      }
    };
  })();

Der Garbagecollector schlägt in fast allen Systemen zu, wenn kein Speicher mehr frei ist. Dies kann sehr lange dauern, da auch eventuell vorhandene Auslagerungsdateien mitgerechnet werden. Das wäre aber der schlimmste Fall und würde spürbar sein (Das System ist dann schwer ausgelastet).

In JavaScript kann man durch die Zuweisung von null das Zerstören des Objectes bzw. der Variablen erzwingen.
Dieses sollte immer dann verwendet werden, wenn sich um ein globalses Object handelt, da dieses bis zum Schließen des Fensters erhalten bleibt.

Vielleicht hilft es.

Zusätlich, wurde ja schon erwähnt, hilft es auf Inlinefunctionen zu verzichten, da auch hier jedesmal der Programmcode und der Speichercode reserviert wird.

Grüße

[Chris M.]

Erst mal danke, dass Ihr helfen wollt, hier besser zu werden!

nach kurzem überfliegen von How to write low garbage real-time Javascript

Spannender Artikel! Wir haben hier den Vorteil, dass wir kein real-time haben, zumindest keines im Sinne des Artikels. (Dort geht es um Animationen in Echtzeit, d.h. man hat nur ca. 13 ms Zeit alles zu berechnen und darzustellen - ein Garbage Collector Lauf kann da alles kaputt machen und sich in üblem Ruckeln äußern. wird bei uns bei den 3D-Seiten wichtig werden... Aber wenn die CV mal ein Widget um 100 ms später aktuallisiert wird das kaum einer merken)

glaube ich für den Watchdog folgendes verstanden zu haben:

In der bisherigen Implementierung erzeugt jeder Ping eine neue Funktion, die dann wohl auch jedes Mal die Variablen neu enthält. Dadurch wird auch jedes Mal der notwendige Speicher allokiert.

Die saubere Lösung wäre laut dem Artikel die Funktion statt inline schon beim startup zu initialisieren und dann nur noch aufzurufen, wobei die Funktion dafür ggf. wohl angepasst werden müsste...

Ansonsten läuft - soweit ich den Artikel verstanden habe - die GC quasi nach Lust und Laune des Browsers.

Der Zeitbedarf des GC stört mich (noch) nicht - mich stört, dass der Speicher nicht freigegeben wird.

Der Garbagecollector schlägt in fast allen Systemen zu, wenn kein Speicher mehr frei ist. Dies kann sehr lange dauern, da auch eventuell vorhandene Auslagerungsdateien mitgerechnet werden.

Richtig, daher darf man auch nicht per top o.ä. nachsehen. Aber die Entwickler-Tools im Chrome machen explizit einen GC-Lauf vor dem Speicher-Report, d.h. da kann man sauber die Heap-Snapshots vergleichen.

In JavaScript kann man durch die Zuweisung von null das Zerstören des Objectes bzw. der Variablen erzwingen.
Dieses sollte immer dann verwendet werden, wenn sich um ein globalses Object handelt, da dieses bis zum Schließen des Fensters erhalten bleibt.

Vielleicht hilft es.

Mit war der Unterschied zwischen Nullen und delete neu, danke!
Wobei man hier aufpassen muss, da wohl viel gefährliches Halbwissen im Netz (insb. auch auf StackOverflow) verteilt wird. Interessant in diesem Kontext ist Perfection kills » Understanding delete

Zusätlich, wurde ja schon erwähnt, hilft es auf Inlinefunctionen zu verzichten, da auch hier jedesmal der Programmcode und der Speichercode reserviert wird.

In JavaScript auf Inline-Funktionen zu verzichten wäre wie zum 100 Meter-Laut in Kettenhemd und Ski-Schuhen anzutreten.

Aber man könnte evtl. ja etwas mehr recyclen (womit sich der Kreis zum Real-Time Artikel schließt...)

[makki]

Also nachdem ich nun auch meine Seele an Larry verkaufe zwei Fakten:
- in Default-Einstellungen wirds eh gekillt
- Memleaks sind wohl normal, das klingt bitter, ist aber so.. Android, iOS und WG haben dafür ihre Mittel - ist zwar technisch blöd - aber doch sonnvoll..

Makki