News Firefox wird zum Multi-Prozess-Browser

Oder auch so ;) ich hab nur 2 Erweiterungen derzeit, also Java, und Skype-Erweiterung...
 
leider steigt auch der Speciherverbrauch an...
Endlich bekommen quadcores auch beim surfen...ihre Berechtigung^^
 
FF RC3 ist jetzt auch schon erschienen: Englisch
Die deutsche Version leider noch nicht aber den ordner gibts schon. also kann sich nur mehr um stunden handeln: Deutsch

Edit wegen unter mir^^
Ja das weiß ich eh aber es gibt schon zumindestens schon einen möglichen kandidaten und wie ich das so mitbekommen hab gibts genug die jede auch noch so kleine neue version sofort testen müssen.

Edit2:
Also fertiges RC3 ist vorhanden: http://releases.mozilla.org/pub/mozilla.org/firefox/releases/3.5rc3/win32/de/
 
Zuletzt bearbeitet:
Nix da. Das ist eine Nightly, die eventuell zum RC3 werden kann. Siehe auch den Verzeichnisnamen (nightly/...candidates/build2).
 
riDDi schrieb:
Mein Opera 10 hatte heute mit 10 Tabs 55 MB verbrauch, waehrend bei einem Kollegen den FailFox bei 2 Tabs schon mehr als 300 MB hatte. Von daher zweifle ich die Statistik etwas an. Der 3.5 war besser, hatte aber trotzdem noch 75 MB. Von daher kann ich zum Bild nur eines sagen => traue niemals einer Statistik, die du selber nicht gefaelscht hast ;).
 
MountWalker schrieb:
Der Punkt ist, dass diese Prozesse halt übermäßig Systemresourcen fressen - das ist nicht nur Seicher, sondern auch Prozessorzeit, die für diesen Verwatungsaufwand flöten geht. Auf meinem iBook G4 1,33 GHz mit 1,5 GiB RAM ist Webbrowsen wie bereits gesagt heute schon eine Qual.
:rolleyes:

Speicherverbrauch:
Bei jedem halbwegs modernen Betriebssystem, sogar bei Windows, wird nicht der 10-fache Speicher belegt, wenn man das gleiche Programm 10 mal startet, also 10 Prozesse neu erzeugt. Der eigentliche Programmkode belegt dann trotzdem nur einmal Speicher. Der Umstieg auf ein Modell mit mehreren Prozessen muß also nicht notwendigerweise den Speicherverbrauch deutlich steigen lassen.

Prozessorzeit:
Der wesentliche Unterschied zwischen Threads und Prozessen hinsichtlich Rechenzeit entsteht durch den beim Prozesswechsel mitwechselnde Adressraum, während die Threads alle im gleichen Adressraum laufen. Die durch mehrere Prozesse bei einem Browser entstehenden "Verzögerungen" liegen irgendwo im Mikrosekundenbereich - nichts, was man auch nur ansatzweise bemerken würde.

Marcel^ schrieb:
Man könnte es auch so regeln:
Der Browser (der ja als intelligent wie nie angepriesen wird :p) schaut sich an, wieviele Kerne die CPU hat. Ist ein Tab geöffnet, ist wie bisher immer nur ein Prozess geöffnet. Dann wird pro weiterem Tab je ein weiterer Prozess geöffnet - bis jeder Kern einen Prozess zugeteilt bekommen hat. Danach werden mögliche weitere offene Tabs weiter auf die Prozesse 1-x verteilt.
Quatsch. Es ist Sache des Betriebssystems, rechenwillige Prozesse/Threads sinnvoll auf die CPUs zu verteilen. Auf den meistens Rechnern laufen außer dem Browser noch paar andere Programme, an die zu denken ist. Nur das Betriebssystem hat darüber einen Überblick und kann entsprechend sinnvoll agieren.

neo-bahamuth schrieb:
Browserbenchmarks halte ich für so ziemlich die nutzlosesten Benchmarks, als ob es jmd. kümmert, wenn eine Seite ne Sekunde schneller gerendert wird.
Bei Browserbenchmarks gehts nicht so sehr um die Renderzeit für HTML-Seiten sondern sehr um Javascript-Krempel. Heutzutage gibts darauf basierende, interaktive Anwendungen, die sich so verhalten, wie man es sonst von eigenständigen, komplett lokal als Binary laufenden Programmen gewöhnt ist. Je nach Browser/Script-Engine fühlen sich solche Anwendungen sehr unterschiedlich schnell an. Es ist also durchaus sinnvoll, sowas mit Benchmarks zu vergleichen.
 
Zuletzt bearbeitet:
tja, einige Funktionen und Tolls im Firefox sind genial :) Videodownloader steht an erster Stelle :D
 
mensch183 schrieb:
Bei jedem halbwegs modernen Betriebssystem, sogar bei Windows, wird nicht der 10-fache Speicher belegt, wenn man das gleiche Programm 10 mal startet, also 10 Prozesse neu erzeugt. Der eigentliche Programmkode belegt dann trotzdem nur einmal Speicher.
Aber nicht unter Windows. Hier bekommt jeder Prozess seinen eigenen virtuellen Adressraum und damit letztendlich unterschiedlichen physischen Speicher.
 
gruffi schrieb:
Aber nicht unter Windows. Hier bekommt jeder Prozess seinen eigenen virtuellen Adressraum und damit letztendlich unterschiedlichen physischen Speicher.
Auch bei Windows ist es so wie ich es beschrieb. Natürlich bekommt jeder Prozess einen eigenen virtuellen Adressraum. Das heißt aber noch lange nicht, daß der benutzte Bereich jeweils vollständig auf unterschiedlichen physischen Speicher gemappt wird.

Ein Beispiel machts vielleicht am besten deutlich:
Stell dir ein Programm mit 20 MB statischem Code und 5 MB dynamischen Daten vor. Das Programm wird 10 mal gestartet. Was passiert? Es entstehen 10 neue Prozesse mit jeweils eigenem virtuellen Adressraum. Die 20 MB Code all dieser 10 Prozesse werden aber auf den gleichen physischen Speicher gemappt, verbrauchen also nur einmal RAM, nicht 10 mal. Du brauchst somit für die 10 Prozesse nicht 10*(20+5) MB sondern nur 20+(10*5) MB physischen Speicher.

Das entspricht übrigens grundsätzlich dem gleichem Verbrauch, wie wenn du das Pogramm als ein Prozess aber multithreaded erstellt hättest. Dann gäbe es zwar dank nur eines Prozesses nur einen virtuellen Adressraum, aber darin auch nur einmal die 20 MB Code und 10 mal die jeweils 5 MB Daten, auf denen die Threads rumwurschteln. Threads sind _kein_ Mittel, um mit weniger RAM im Rechner auszukommen.
 
Zuletzt bearbeitet:
mensch183 schrieb:
Auch bei Windows ist es so wie ich es beschrieb. Natürlich bekommt jeder Prozess einen eigenen virtuellen Adressraum. Das heißt aber noch lange nicht, daß der benutzte Bereich jeweils vollständig auf unterschiedlichen physischen Speicher gemappt wird.
Doch, tut er. Wie soll das auch anders funktionieren? Schliesslich gibt es auch im Code Segment variable Daten. Wenn es die nicht gäbe, wäre deine Überlegung theoretisch umsetzbar. Praktisch kommt das aber so gut wie nie vor.
 
Zuletzt bearbeitet:
gruffi schrieb:
Doch, tut er. Wie soll das auch anders funktionieren? Schliesslich gibt es auch im Code Segment variable Daten.
Du verwurschtelst beides. Variable Daten und Code sind 2 paar Schuhe. In aller Regel ist der Code unveränderlich. Veränderlicher Code, also sich selbst modifizierender Code, ist die große Ausnahme, nicht die Regel.
 
Ich glaube nicht, dass er von sich modifizierendem Code spricht, sondern einfach nicht was was ein Code Segment ist. Zumindest nicht so richtig.
 
das wird dann aber noch mehr RAM fressen oder?
 
mensch183 schrieb:
Du verwurschtelst beides. Variable Daten und Code sind 2 paar Schuhe. In aller Regel ist der Code unveränderlich. Veränderlicher Code, also sich selbst modifizierender Code, ist die große Ausnahme, nicht die Regel.
Ich rede nicht von Code Morphing. Code Segment und Daten Segment werden doch sowieso über den gleichen Deskriptor angesprochen. Es ist kein Problem, Daten zwischen Code Sequenzen unterzubringen. Und das wird in der Praxis auch oft gemacht.
Mir ist auch nichts davon bekannt, dass Windows verschiedene Instanzen derselben Anwendung auf demselben physikalischen Speicher abbildet. Falls doch, bitte ich um Quellen.
 
BrollyLSSJ schrieb:
Mein Opera 10 hatte heute mit 10 Tabs 55 MB verbrauch, waehrend bei einem Kollegen den FailFox bei 2 Tabs schon mehr als 300 MB hatte. Von daher zweifle ich die Statistik etwas an. Der 3.5 war besser, hatte aber trotzdem noch 75 MB. Von daher kann ich zum Bild nur eines sagen => traue niemals einer Statistik, die du selber nicht gefaelscht hast ;).
Das kommt sicherlich sehr stark drauf an, welche und wie viele Erweiterungen man installiert hat. "noch" 75? Surft er mit 512 MB RAM?
 
LHB schrieb:
und gibts dafür auch:

SCREENGRAB
MAUSGESTEN
DOWN THEM ALL
COLORFULL TABS

usw.

?????????????

"Paste and Go" ist mal die unscheinbarste, aber genialste "Erfindung", die mich auf ewig an Opera heften wird :D
 
Zurück
Oben