Urban75 Home About Offline BrixtonBuzz Contact

Firefox is a beast!

Agreed. But still nowhere near as fast as Opera :P

Whilst that comment should be taken with a pinch of salt, FF3 *still* gobbles up huge amounts of memory if you leave it long enough. I left the beta 3 running over the bank holiday weekend on my work machine (installed it on monday or tuesday I think) with about twelve tabs open, and it was chomping 1.2GB resident VM when I got in this morning (compared to opera 9.5 with ~40 tabs open which was chomping about 150MB). I'm used to measuring Opera's uptime in weeks.

Secondly is FF's inherent threading issues. Ever load a page and notice the entire interface becomes sluggish, to the extent that you can't switch to another tab or load a menu? This is because the JS interpreter used to render web pages is also used to render the UI, and because it's inherently single-threaded you can't render both at the same time. FF3 is an improvement, but gestures are still laggy enough to be unusable IMHO. Maybe I'm spoilt by Opera's "I'll do everything instantly".

Some may consider FF the poster-child for open source, but if so it makes me think of the children in the Childline campaigns.

Nope, I suggest you read the Firefox architecture document. How could a JS interpreter render anything? Multi-threading != Faster systems.
 
Nope, I suggest you read the Firefox architecture document. How could a JS interpreter render anything? Multi-threading != Faster systems.

FF uses XUL as an interface language which is rendered by gecko, and it incorporates JS.

XUL relies on multiple existing web standards and technologies, including CSS, JavaScript, and DOM.

http://en.wikipedia.org/wiki/Xul

FF3's improved "teh snappiness" is mostly due to an improved JS JIT named Tamarin, which was mostly written by Adobe and then integrated with Seamonkey to provide a complete, half-rewritten, JS engine. It's much better at concurrency and spreading the load evenly, but if you have a JS-heavy page it'll still slow the UI down to a crawl.

http://ajaxian.com/archives/the-hardware-of-tomorrow-versus-the-platform-of-tomorrow

If you use the gecko engine in an app that doesn't use XUL for the UI, you get a blazing fast browser with rendering speed and responsiveness in the same ballpark as Opera.

Anyways, guess you can argue about it any which way you like, but until I see seamless gesture support in FF it'll be relegated to a second class citizen IMHO.
 
FF3's improved "teh snappiness" is mostly due to an improved JS JIT named Tamarin, which was mostly written by Adobe and then integrated with Seamonkey to provide a complete, half-rewritten, JS engine. It's much better at concurrency and spreading the load evenly, but if you have a JS-heavy page it'll still slow the UI down to a crawl.

Isn't Tamarin going to be introduced in Firefox 4...? :confused:

Version 4.0

On October 13, 2006, Brendan Eich, Mozilla's Chief Technology Officer, wrote about the plans for Mozilla 2, the platform on which Firefox 4.0 is likely to be based. These changes include improving and removing XPCOM APIs, switching to standard C++ features, just-in-time compilation with JavaScript 2 (known as the Tamarin project), tool-time and runtime security checks.[134][135] It has also been announced that support for the Gopher protocol will be removed by default for Firefox version 4. It is likely to be supported as an addon if an owner steps up to do the work.
http://en.wikipedia.org/wiki/Firefox_3#Version_4.0

The earliest web browser it appears in will be SeaMonkey...

Tamarin will support the forthcoming ECMAScript Edition 4 ("JS2") language and will be integrated into SpiderMonkey as part of the Mozilla 2 project, to be released in 2008. Brendan Eich's Roadmap Update for Mozilla 2 provides broad details on Mozilla 2 and Tamarin's role in this roadmap.
http://www.mozilla.org/projects/tamarin/
 
FF3's improved "teh snappiness" is mostly due to an improved JS JIT named Tamarin, which was mostly written by Adobe and then integrated with Seamonkey to provide a complete, half-rewritten, JS engine. It's much better at concurrency and spreading the load evenly, but if you have a JS-heavy page it'll still slow the UI down to a crawl.

Isn't the "snappiness" down to re-writing Gecko to use Cairo...? And then actually using a decent memory allocator...? :confused:

If you use the gecko engine in an app that doesn't use XUL for the UI, you get a blazing fast browser with rendering speed and responsiveness in the same ballpark as Opera.

Well... Firefox 3 uses Xul for the UI AFAIK and feels as snappy as Opera...
 
Back
Top Bottom