Es ging ihm wohl eher darum, dass die Methode "Ein Prozess pro Tab" - von einer minimalen Geschwindigkeitssteigerung abgesehen - keinen merklichen Vorteil für den Benutzer bringt.Zitat von Jesus_666
@init
Was ist eigentlich aus init-ng geworden?
Donnerwetter ^^
Wenn es richtig implementiert ist bringt es Vorteile – ein hängenbleibender Tab reißt nicht den gesamten Browser mit. Daß Google keine Erfahrung in Kerneldesign hat (denn das Chrome-Kernprogramm repliziert einiges an traditioneller Kernelfunktionalität) bedeutet nicht, daß das Konzept nicht funktionieren kann.
Nebenbei macht das ein-Tab-ein-Prozess-Paradigma den Browser eher langsamer als schneller, weil es zusätzlichen Overhead gibt. Das Ziel ist nicht Geschwindigkeits- sondern Stabilitätsoptimierung.
Chromes Geschwindigkeitsvorteil kommt von der Kombination Webkit/V8 – die Renderengine ist momentan als sehr schnell bekannt und die JavaScript-Runtime ist einfach eine der ersten am Markt, die JIT-Kompilierung verwendet. Mozilla hat sowas auch, Tamarin wird aber erst in Fx 4 zum Einsatz kommen.
Ist noch nicht stable, aber in den Paketmanagern aller großen Distros zu finden.
Hossa. Mozilla hat die erste Firefox 3.1-Beta rausgebracht - mit TraceMonkey, einer Weiterentwicklung der aktuelen JavaScript-Engine SpiderMonkey. TraceMonkey hat schon einen JIT-compiler und kann sich von der Geschwindigkeit her mit V8 messen.
In den unteren Grafiken sieht man, daß V8 in einigen Bereichen immer noch deutlich schneller ist, aber das liegt daran, daß Mozilla noch nicht dazu gekommen ist, diese Teile neu zu machen – mal sehen, wie's bei der Fx 3.1-Final aussehen wird.
Auf jeden Fall ein böser Rückschlag für Google – Chrome wird eine ganze Ecke unbesonderer.
Sollen sie sich nun in die Ecke setzen und rumheulen. Google hat nun seinen Spaß gehabt und langsam ist's auch gut. Ist's nicht eigentlich so ziemlich Gurke, welcher Browser nun 1µs schneller ist? Neue Funktionen, die nicht Anbietergebunden sind, wären etwas, das Interesse rechtfertigen würde. Schneller höher weiter haben wir schon im Mikroprozessormarkt.
Pssst! Du machst den Browserherstellern ihre schonen JavaScript-Geschwindigkeits-Schwanzvergleiche kaputt! Wenn sie die nicht hätten müßten sie wieder an Sachen wie DOM-Support, Sicherheit oder gar CSS3 arbeiten.
Nicht mal CCS2 beherrschen die Browser korrekt und da kommst du mit CSS3.
Schäm dich!
--
Was, jetzt sollen sie auch noch die aktuellen Standards zuende implementieren, bevor sie mit den unfertigen nächsten anfangen? Was kommt als nächstes, XHTML-Support im Internet Explorer?
Und hier nochmals: http://webstandard.kulando.de/post/2...-google-chrome
"Oh mein Gott! Wir müssten ja wieder innovativ sein und/oder uns an die Implementierung der Standards setzen, die schon seit Jahren bei uns in der Ecke verschimmeln... Lasst uns lieber noch ein wenig die Geschwindigkeit pimpen und so noch etwas Zeit schinden..."
Naja, es st nicht so, als ob sie nicht an den Standards arbeiten wollen, aber Standards sind einfach nicht sexy. Momentan will jeder mehr JavaScript, mehr JavaScript und vielleicht noch besseres JavaScript. Es ist momentan eben der große Trend, schlechte Kopien von Desktopanwendungen in JS zu schreiben; HTML und Websites sind ja sowas von 1998...
Das überhaupt nicht dran gearbeitet wird, wollte ich damit auch nicht ausdrücken. Ich finde es aber sch~ade, dass Geschwindigkeit eine viel höhere Priorität (nicht, dass sie vollkommen unwichtig wäre...) zu haben scheint, als die Implementierung von (schon seit längerer Zeit stehenden) Standards.
Was ist nur aus der guten alten Webseite geworden, die nur mit (X)HTML und CSS auskommt? ^^
Also in den release notes der bisherigen Developer Previews von Safari 4 steht's nicht drin. Aber, ja, weitere Verbreitung dieses Features wäre cool.
Berechtigungen
Zitieren
