Am Anfang war ich vom Dashboard und den Widgets begeistert. Grundsätzlich finde ich das Konzept immer noch sehr gut. Dennoch habe ich mich entschieden, in Zukunft auf DB zu verzichten. Die Widgets fressen mir zu viel RAM. (Wer mehr als 1 GB RAM in seiner Kiste hat, wird die Tatsache, dass jedes Widget +/- 10 MB RAM vertilgt wahrscheinlich weniger stören). Ich frage mich, woran es liegt, dass Widgets im Vergleich zu “richtigen” Programmen überproportional viel RAM verbrauchen. Hat jemand eine Erklärung dafür?
Da dieser Vorwurf ist überall zu lesen ist, möchte ich mal meine 2 Rappen dazu geben. Ich habe folgendes Experiment gemacht. Zuerst Dashboard geöffnet. Wie erwähnt braucht jedes Widget etwa 10 MB, die beim Schliessen von Dashboard auch nicht zurückgegeben werden, da ich noch genügend freies Memory hatte. Nun habe ich Photoshop geöffnet und ein Riesenbild erzeugt, mit dem Effekt, dass die Widgets brav ihr Real RAM bis auf ein paar Hundert kB abgegeben haben. Also nicht von Memoryfressern. Hier ein Schnappschuss von Top (fett hervorgehobene Zahlen zeigen die aktuelle Belegung von RAM:
Also alle Widgets belegen nur etwas unter 1MB. Beende ich Photoshop, werden wieder ca 600MB RAM frei ohne dass die Widgets sich gierig auf das freie RAM stürzen. Erst wenn ich Dashboard wieder anklicke und ein Widget brauche, steigt der reale Speicherbedarf an.
Dies scheint ein ganz normales Verhalten einer Anwendung zu sein. Solange genügend RAM zur Verfügung steht bleibe ich im Hauptspeicher. Brauchts eine andere Anwendung dringender, begebe ich mit in den Swapbereich. Natürlich wird das Swapen auf Disk den Ablauf verlangsamen, aber das gilt für alle Programmwechsel bei ungenügendem RAM.
Interessante Beobachtung, die sich leider nicht meinen Erfahrungen deckt. Da ich nur 512 MB RAM in meinem Mac mini und 768 MB in meinem PB habe, habe ich schnell (besonders beim mini) nur noch wenige MB frei. Dennoch wird nur die Auslagerungsdatei vergrössert, dass die Widgets ihr RAM zurückgeben würden, konnte ich bis jetzt nicht beobachten.
So sollte es im Prinzip auch sein. Warum es bei mir nicht funktioniert, weiss ich nicht. Die einzige Erklärung wäre, dass das Speichermanagement von OS bei viel RAM wesentlich effizienter ist, als bei wenig RAM.
Danke berwis, für deinen Heinweis, ich werde das Ganze noch einmal etwas genauer beobachten. :)
(Bearbeitet am 03. Oktober 2005 um 11:31 Uhr von )
Eine Meinung aus dem Bauch heraus. Vielleicht ist Dashboard so greedy wie die Musikindustrie :c und gibt das RAM nur wenn unbedingt nötig zurück, lässt dabei lieber andere Programme bluten. Wechselt man dann z.B. von Word zu FileMaker hin und her wird immer ein Teil der nicht gebrauchten Anwendung geswapt mit all den lästigen Wartezeiten und Dashboard lacht sich ins Fäustchen. Aber das ist nur eine Vermutung. Vielleicht musst du mal nur eine RAM-fressende Applikation aufmachen, die praktisch den ganzen Speicher belegt, und dabei das Verhalten der Widgets beobachten.
Ich habe gerade eine 379 MB grosse PDF-Datei mit Adobe Reader 7 geöffnet.Die Widgets haben rund 30% ihres RAMs abgegeben, der Rest wurde aber von anderen Programmen abgezweigt, bzw. geswapt. Dashboard scheint tatsächlich gewisse Änlichkeiten mit der Musikindustrie zu haben. :D
Habe auch immer Probleme mit dem Dashboard, will man mal etwas kurz nachschauen im Teletext oder so, muss ich am Anfang immer ca. 20sek. warten das nervt echt !! 😠
Ich habe leider auch nur 768 MB RAM und mit ein paar Widgets wartest du jedesmal ne Weile, da bin ich schneller, wenn ich direkt im Web nachschaue !
…da fragt sich der Sinn dieser Widgets. Vor allem auch die, die nur eine Verlinkung an den Browser weitergeben, da geh ich lieber in meine Lesezeichen, bin ich schneller !
Der von Berwis beobachtete Effekt existiert schon, die Ursache liegt im den Multitasking-Fähigkeiten von OS X.
Die zur Verfügung stehenden Ressourcen (Prozessorzeit, Speicher), werden vom Kernel an die einzelnen Prozesse verteilt. Solange genügend RAM frei ist, wird dieses auch vergeben (solange die ‘Nachfrage’ besteht). Ein Dashboard-Widget benötigt im Schnitt etwa 7 MB. Das Problem beginnt eigentlich erst dann, wenn nicht mehr genügend RAM frei ist. Dann versucht der Kernel, den Speicher möglichst effizient zu verwalten. Damit wird gewährleistet, dass auch bei vielen offenen Programmen z.B. das Dock oder die iTunes-Musik flüssig läuft. Jeder Prozess erhält eine bestimmte Priorität und anhand dieser Priorität wird der Speicher verteilt. Wenn der einer Applikation zugewiesene Speicher nicht ausreicht, werden Daten auf die HD ausgelagert. Die Speicherzuweisung obliegt einzig und allein dem System-Kernel. Es gibt keine ‘geizigen-Programme’. Wenn die Nachfrage nach Speicher 4 Mal so gross ist wie das Angebot, lagert auch das Dashboard drei Viertel seiner Daten auf die Festplatte, genauso wie jedes andere Programm - Ausser es besitzt eine höhere Priorität, z.B., wenn es gerade aktiv ist.
Mit der ursprünglichen Frage von Zaty hat das aber nichts zu tun. Denn obwohl ein Programm nie ‘Speicher nicht abgeben’ kann, hängt der Speicherbedarf mit der Effizienz der Programme zusammen. Wenn eine Applikation eine sehr hohe Speichernachfrage generiert, erhält es auch verhältnismässig viel RAM. Je mehr Bilder ich z.B. mit Photoshop öffne, desto grösser wird die Speicher-Nachfrage von PS, dadurch erhält es eine höhere Priorität und letztendlich auch mehr Speicher.
Es stimmt, dass 7 oder 10 MB für so ein kleines Programm wie ein DB-Widget verhältnismässig viel sind. Der Grund liegt vermutlich darin, dass Widgets sehr einfach erstellt werden können. Sie werden ähnlich programmiert wie eine Website, was überhaupt nicht hardwarenah ist. Eine mit z.B. Objective-C erstellte Applikation wird aufwändig und hardwarespezifisch kompiliert. Ein Widget hingegen wird während dem Starten gewissermassen in Echtzeit kompiliert, ähnlich wie ein Java-Applet (deshalb ist es auch plattformunabhängig). Mit anderen Worten: Während ein ‘normales’ Programm direkt mit dem Kernel kommuniziert, läuft ein Widget vermutlich nur in einer speziellen Laufzeitumgebung, welche die Befehle der Widgets laufend in maschinellen Code übersetzt. Somit fällt jegliche Optimierung, die ein anderes Programm durch manuelles Optimieren durch den Programmierer oder durch automatische Optimierung durch den Compiler erhält, weg.
Die Widgets laufen doch auf dem Webkit et al - und schlecht optimiert ist der nicht (mehr), oder ?
schlechte Widgets kosten RAM und CPU. Ich hab gelernt, dass man nur ganz einfach Widgets haben sollte. Media Player und andere kosten zu viel Resourcen.
jedes Widget ist eine gescriptete Webseite, die viel Javascript und CSS braucht, und fast zu 100% aus graphiken besteht. Irgendwo müssen die sein. Guck mal an, was Safari “frisst” wenn du paar Fenster aufhast ;-)
Die Widgets reduzieren ihre RAM Bedarf sicherlich, bzw Tiger arbeitet da erfreulicherweise sehr gut, dennoch bleibt der Wermutstropfen, dass der VM stärker belastet wird und die gefühlte Performance reduziert wird. Dies mag vielleicht nicht für einen Dual G5 gelten, aber zB für mein klein’ süss’ iMac g
Das Widget “Television Vf1” kostet hier enorme Resourcen, und teilweise auch ne systemlast von 30% ;-) Aber nett wärs schon gewesen …
Anmelden um neue Antworten zu verfassen
Allegra Leser! Nur angemeldete Nutzer können bei diesem Beitrag Antworten hinterlassen. Jetzt kostenlos registrieren oder mit bestehendem Benutzerprofil anmelden.
Ab CHF 5.– im Monat
👉🏼 Wir benötigen deine Unterstützung! Unterstütze macprime mit einem freiwilligen Gönner-Abo und mache die Zukunft unseres unabhängigen Apple-Mediums aus der Schweiz mit möglich.
macprime unterstützen
macprime ForumWidgets sind RAM-Fresser
VonAntwort von Thomas Zaugg
Unsere Sponsoren
Apps with love entwickelt digitale Produkte, die das Leben vereinfachen.
Dich als Sponsor präsentieren und macprime mit möglich machen.
berwis
Thomas Zaugg
(Bearbeitet am 03. Oktober 2005 um 11:31 Uhr von )
berwis
Thomas Zaugg
Hitsch
dae
Thomas Zaugg
Solaris
Anmelden um neue Antworten zu verfassen
Allegra Leser! Nur angemeldete Nutzer können bei diesem Beitrag Antworten hinterlassen. Jetzt kostenlos registrieren oder mit bestehendem Benutzerprofil anmelden.