Ich überlege, wie ich den Speicherverbrauch (Arbeitsspeicher) einer umfangreichen js-Anwendung messen kann bzw wie ich herausfinden kann, ob/ wann der interne Garbage-Collector tatsächlich bestimmte sehr große freigegebene ( hoffentlich nicht mehr referenzierte bzw auf NULL gesetzte) Objekte entsorgt.
Die Anwendung ist in einem html-Dokument eingebettet -> wird also im Browser ausgeführt (nicht jsnode oder vergleichbares).
Verwendetes Entwicklungssystem: Ubuntu 10.04 / Mozilla 3.6.17
Hat jemand eine Idee?

Dank an euch beide für den Tip, den Taskmanager von Chrome zu nutzen. Für meine Zwecke wird es reichen, es geht um einen groben Überblick und ein paar Tests, ob sich Teile der Anwendung sinnvoll beenden lassen und der dafür verwendete Speicher wieder freigegeben wird, ohne die gesamte Anwendung zu schließen ( memory leaks).

@ wischi
Ich schätze deine Kompetenz in manchen Bereichen, aber

Zitat

...oder du meinst java. dass hat mit js nix gemeinsam...

ich schrieb von javascript und nicht von java. Die Unterschiede und Gemeinsamkeiten sind mir bestens bekannt.

Um Mißverständnissen vorzubeugen, habe ich im Post oben extra auf node.js (ok, ich schrieb von jsnode) hingewießen und die Einbettung des Javascripts im html-Dokument erwähnt.
Neben node.js , JSR 223 (und standardmäßiger Js-Engine Implementation in der JVM), sowie QTScript (QtWebKit, Qt Quick), gibt es etliche weitere Engines/ Implementationen, welche Javascripte / ECMA-Scripte nicht unterhalb eines Browsers und/oder eingebettet in html-Dokumenten ausführen können. Z.B. auch der Acrobat Reader und Flash/Flex sind in der Lage, Javascripte auszuführen, Silverlight vermutlich über jscript ebenso.

Meine Absicht ist es, Anwendungen ( man könnte es auch Widgets oder auch Teilanwendung oder haumichtot nennen ) für Web-Desktop-Systeme wie z.B. Eyeos oder Lucide Desktop zu entwickeln. Da hierbei häufig schon das jeweilige Basissystem (EyeOs / Lucide Desktop) relativ ressourcenhungrig ist, möchte ich das Verhalten meiner Teilanwendungen bzw. der gesamten Anwendung (des gesamten Web-Desktops) genauer beobachten und testen.