Mozilla informuje, iż dzięki pracom nad poprawą wydajności Firefoksa, jego nowe, czwarte wydanie bije Chrome pod względem szybkości wykonywania skryptów JavaScript.
Strona porównująca szybkość Firefoksa do dwóch konkurentów – Google Chrome i Safari – „Are we fast yet?” („Czy już jesteśmy szybcy?”) – wykazała na podstawie testów, iż w przypadku benchmarka SunSpider, Firefox po ostatniej aktualizacji rzeczywiście jest szybszy od Chrome i Safari, natomiast w teście v8bench wypada na razie lepiej jedynie od Safari.
Dokładne wyniki zależą od architektury, na której został wykonany test. Podany wyżej rekord dotyczy architektury x86.
Ale co z tego skoro interfejs dalej mulu, przeskakiwanie miedzy kartami przenoszenie kart, wyciąganie karty do nowego okna etc. Silnik FF dla mnie już dawno był BDB, tylko ten mułowaty interfejs i bardzo wolny start.
No właśnie. Czy w FF4 każda zakładka będzie jako oddzielny proces? Miałem zainstalowaną wersje beta6 i tam chyba tak nie było.
Wydaje mi się, że dopóki nie zostanie to sensownie rozdzielone, to mocne mielenie w jednej zakładce będzie wpływało na to co się dzieje w innych. Na razie pod tym względem nawet IE8 wyglądało lepiej niż FF.
Zresztą i tak głównie używam Chrome – FF musi jeszcze wiele się nauczyć 🙂
A wie ktoś jak prace nad Friefoksem z Qt?
QT raczej wiele nie pomoże na Windows a i na Linuksie też dopóki silnikiem będzie XUL a rysowanie to wyłącznie QT. Z QT na FF jest tak, ze projekt co jakiś czas odwieszany i zawieszany.. jednak równie mułowaty jak na GTK, własnie ze względu na silnik XULowy. Rozwiązanie? Korzystać z innych przeglądarek z silnikiem Gecko..
Ale jeśli XUL to javascript, a javascript jest JITowane to czy nie powinno być szybciej? A może chodzi o jakiś totalny design flow do interfejsu jak np. połączenie z wątkiem do renderowania?
Powinno być szybciej, jednak to nie zmienia jednego, ze dalej za wiele jest warstw odpowiedzialnych za interfejs
XUL to naprawdę cudowna, zgodna z XML gramatyka języka opisującego rozmieszczenie elementów GUI i naprawdę jest o niebo lepszy do tych zastosowań od HTML.
http://www.hevanet.com/acorbin/xul/top.xul
XUL używa ZK, luxor, luxor-swt, a sam w sobie nic to nie wini, zresztą istnieje przecież wiele innych gramatyk zgodnych z XML do opisu GUI (mają je wxWidgets, openlaszlo, .NET, itd).
Jeśli chodzi o faktyczny język/runtime logiki GUI, to FireFox faktycznie bazuje głównie na JavaScript w połączeniu z XUL, RDF, XBL i XPCOM.
Architektura FireFox jest naprawdę bardzo zgrabna i miejscami bije na głowę inne runtime’y (niestety nie mogę znaleźć diagramu):
http://appsapps.com/ebooks/?p=195
http://brian.mozdev.org/conferences/dls2006/slides.html
http://bpfx.org/oreilly/Programming_Firefox/OReilly%20Programming%20FireFox.pdf
FireFox ma własny runtime (jak Java, Python, C/C++, .NET, czy inny) z naprawdę zgrabną architekturą złożoną z JavaScript, XUL, XBL, RDF, XPCOM:
http://brian.mozdev.org/presentations/cyberpipe2005/slides.html
http://bpfx.org/oreilly/Programming_Firefox/OReilly%20Programming%20FireFox.pdf
XUL to nie JavaScript (używałem go z czystym Java), XUL jest gramatyką zgodną z XML bardzo dobrze opisującą GUI i jest używana przez framework ZK i luxor.jar/luxor-swt.jar (Java) – podobne gramatyki mają wxWidgets, openlaszlo, .NET i wiele innych, ale XUL wydaje się o niebo lepsze, a szczególnie od HTML:
http://www.hevanet.com/acorbin/xul/top.xul
Cieszymy sie, ze FF ma runtime do Pythona, .NET, erlanga i sranga.
Cieszymy sie rowniez, ze komus wyszedl na papierze ladny diagram.
Niestety, mniej sie cieszymy, ze temacie „przegladarka WWW”
FF jest mulem i nie wyglada tak słitasnie jak na papierze.
> XUL wydaje się o niebo lepsze, a szczególnie od HTML
Co za porownanie, XUL sluzy do opisu GUI, HTML do dokumentow,
choc w sumie na chama mozna zmusic je do roboty odwrotnej.
Powolnosc XULa bierze sie z:
1. Narzut na parsowanie (XML szybki w parsowaniu to nie jest)
2. Narzut na dynamiczne zbudowanie GUI.
Bez wzgledu w czym to zaimplementujesz i jak słitasnie to
wyglada na papierze, to musi byc wolniejsze od klasycznego
„whardkodowania” GUI w aplikacje. Jesli do tego jeszcze uzyjesz
jezyka wyraznie wolniejszego od jezykow natywnych
(JavaScript vs C/C++) masz gui-mula takiego jak FF.
Sorki za post n-razy, ale nie uaktualniało mi się zaraz po poście i próbowałem ponownie.
Wyjaśnienie:
FireFox ma runtime podobny do w/w a nie binding do w/w runtime obcych.
XPCOM to technologia integracji z bibliotekami natywnymi – bardzo podobna do COM od MS.
Samo serce (runtime) FireFo ma napisane w C lub C++ i chyba w całości ukryte za XPCOM i XBL.
Ewentualnym problemem jest więc albo/i:
– sam JavaScript (czy ciągle nie ma w nim czegoś na wzór JIT? [a były takie plany]),
– brak optymalizacji w wielu drobnych kawałkach,
– albo sama ilość warstw i złożona architektura?
Jeszcze raz powtarzam:
XUL nie jest niczemu winne prawie na 100% [to zależy oczywiście od implementacji].
Zauważ, że ten zbiór XUL definiujący wygląd GUI, to nieskomplikowane statyczne zasoby, które runtime wczytuje i parsuje tylko raz [tu trzeba by się upewnić], tworząc wydajny odpowiednik w strukturze obiektów w pamięci, więc nie ma to znaczenia że XUL jest XML, bo zasób binarny przyśpieszył by minimalnie (o pojedyncze milisekundy) jedynie pierwsze ładowanie.
Taka jest cena za rozszerzalność. Dzięki XUL mamy milijon dodatków do Firefoksa, w większości działających na wszystkich platformach. Jeżeli ktoś narzeka na szybkość, może użyć przeglądarki korzystającej z Gecko bez XUL, jak np. K-Meleon czy Camino. Tylko pod X-ami jest problem, jako że Galeon w zasadzie nie jest już rozwijany a Epiphany przełączyło się na WebKit.
LMAO, zgodność z XML jako zaleta, LMAO.
Ale nie płacz. Zainstaluj se IE.
Ok, a gdzie wynik Opery i IE9, tak żeby było sprawiedliwie. Co do ff to na Windowsie działa całkiem znośnie, ale na Linuksie myślałem że się pochlastam. Na szczęście jest opera 😉
Znalazłem odpowiedz w ich faq
Why isn’t Opera/IE/something here?
Right now, the performance tests are run on a Mac, which means no IE. Also the tests rely on a „shell” JS engine that runs in a command line. It doesn’t test browsers. We’ll change that, eventually.
Boją się bezpośrednio porównać do Opery po prostu!
seamonkey bardzo szybko działa w porównaniu z fx, do tego themes Mostly Crystal 😉
To nie porownanie szybkosci przegladarek, ale samych silnikow JS.
http://code.google.com/p/v8/source/detail?r=5692
http://hg.mozilla.org/tracemonkey/rev/2e6b54230d31
Natomist Firefox jest nadal wolniejszy (przynajmniej na Linuksie – wydania nighhtly obu przegladarek).
*1.34x as slow* 329.2ms +/- 4.3% 441.4ms +/- 0.8% significant
FireFox ma własny runtime (jak Java, Python, C/C++, .NET, czy inny) z naprawdę zgrabną architekturą złożoną z JavaScript, XUL, XBL, RDF, XPCOM:
http://brian.mozdev.org/presentations/cyberpipe2005/slides.html
http://bpfx.org/oreilly/Programming_Firefox/OReilly%20Programming%20FireFox.pdf
XUL jest gramatyką zgodną z XML bardzo dobrze opisującą GUI i jest używana przez framework ZK i luxor.jar/luxor-swt.jar (Java) – podobne gramatyki mają wxWidgets, openlaszlo, .NET i wiele innych, ale XUL wydaje się o niebo lepsze, a szczególnie od HTML:
http://www.hevanet.com/acorbin/xul/top.xul
Bez względu na zamiłowania do poszczególnych technologii i tak wielki respect ogólnie dla programistów silników JavaScript (w FF i nie tylko). Wyścig zbrojeń silników JS w ostatnich latach pokazuje jak dużo da się wycisnąć w bardzo krótkim czasie. Gdyby aplikacje w innych segmentach rynku tak przyspieszały… Ah marzenia 🙂
To raczej dogonienie peletonu, a nie samotna ucieczka lidera do przodu.
News powinien brzmieć – „firefox – w końcu dogonił konkurencję”.
A wszystko to pokazuje, że najważniejsza jest różnorodność i konkurencja. Niech żyje wybór.
Widzieliście to?
http://aur.archlinux.org/packages.php?ID=22919
Co o tym sądzicie?
To jeszcze nie ma PGO w buildach dla Linuksa? Kiedys uzywalem (pierwsze wydania z serii 3), ale Fx update’owany jest zbyt czesto, ale podwojna kompilacja troche trwa. Rezultat jakis tam jest, ale (imho) w granicach efektu placebo.
to jest zapewne od mozilli i nie mozna im wierzyc.
W Firefoxie przydałoby się przyspieszyć interfejs, zamiast bebechów.
Najlepiej, jakby porzucili wreszcie ociężałe i przestarzałe GTK na rzecz nowoczesnego i lekkiego Qt4.
Nie ma Firefoksie nowoczesnego gtk+, a port na przestarzałe qt chyba już umarł.
LOL, lekke i Qt4 w jednym zdaniu? tiaa. Masz kazehakase, czyli gtk na xulrunnerze, czy midori – gtk na libwebkicie. Przy nich „lekkie i nowoczesne” konquerory, arory czy rekonqi to muly jak cholera.
1) konqueror i rekonq to nie Qt tylko kdelibs.
2) konqueror i rekonq mają bardzo szybki interfejs – kwestia renderowania itd. to już specyfika danej aplikacji, a nie toolkitu.
3) Qt jako toolkit do tworzenia interfejsu jest BARDZO szybkie w porównaniu z GTK.
Tak Qt jest tak szybkie, że wyświetla się zanim programista nawet pomyśli co chce wyświetlić.
Próbowałem kiedyś Midori i ciężko to się używało, bo nonstop się wywalała. Używałem za to Arory na qtwebkit i sprawuje się znakomicie – szybko i stabilnie.
Ja tu nie mowie co jest lepsze czy stabilne. Przegladarki staly na tyle zaawansowanymi programami, ze nawet nie spogladam na male projekty. Nie uzywam zadnej z wymienionych, to byla tylko odpowiedz na trolowa zaczepke oO.
Odpalilem Arore, 3s rysuje mi sie interfejs, odpalam kilka pustych tabow, szybka zmiana za pomoca scrola, ~40% obciazenia C2D. Skalowanie okna – miazga – ze 2-3 redrawy na 1000px, scrolowanie na granicy plynnosci. Midori odpala sie i rysuje niemal natychmiast. Ten sam motyw z tabami, ~10% CPU. Skalowanie okna bardzo plynne, scrolowanie bardzo plynne.
Midori szybko się rozwija, z wersji na wersję jest coraz lepiej, tak więc polecam sobie skompilować najnowsze wydanie. No i warto mieć w miarę świeżego WebKita.
Cieszym się niezmiernie że to z troski, że zależy waszmości na szybkości.
kolejny troluje o GTK… odwal sie od niego do cholery
Wydajność może i ma troszkę niższą od Chroma ale ostatnio, w związku z awarią sprzętu musialem zwrócić uwagę na inny parametr – pamięciożerność. Bylem zmuszony przesiąść się na zakurzone T40 z 768MB RAM i WinXP na pokładzie. O ile Chrome ciut szybciej śmigał, o tyle miał też większy apetyt na pamięć. Koniec końców zostałem przy FF3.6.
Miłe są też optymalizacje wykorzystania pamięci w FF (3.6.11) – widać jak ładnie przydziela i po jakimś czasie zwalnia nieużywaną. W zapomnienie poszly czasy gdy ta przegladarka na systemie wielokrotnie hibernowanym i wznawianym zajmowała pod 1GB (kilkanascie okien po kilkanascie zakladek w kazdym, nierzadko zawierające youtuba i inne serwisy z ciezką zawartościa). Mimo zamykania kolejnych okien zajętość nie spadała.
Osobnym tematem jest marketing gógla wciskającego swoją „kulawą” przegladarkę do wszystkiego co się da bez możliwości nieinstalowania. Mam na myśli przykładowo ichniego Ertha – przynajmniej do niedawna nie dalo sie bez.