Faster in what sense? In addition to the "how long does it take the benchmark" number there is the "how long does it take to start up" number and the "how much memory does it use" number. Last I checked the JVMs weren't so hot on the latter two no matter how they did on the former.
I meant a particular subtest of the benchmarks. The better benchmarks aim to have a variety of tests that exercise as much of the engine's functionality as possible.
You're assuming that "V8" and "Tracemonkey" (and "SFX", for that matter) are frozen entities. They happen to be in active (furious, really) development, so the relative speeds change daily if not more often. Especially if you pick a particular test.
Bingo. What it comes down to is that the answer to "Is X faster than Y" will depend on two things:
1) The benchmark 2) The day of the week (or the exact, to the minute builds you're testing, if you prefer)
The reason for the latter is that all three are in active development. Each one is doing measurements right after landing major changes, against whatever the current state of the other two is. That means that there is inherent bias there in favor of whoever is doing the measurements being fastest: they've just hopped a step up in performance while the other two engines are on the same step they were at 3 minutes ago.
The same thing will happen with stable releases, for what it's worth. Safari 3 shipped a faster JS engine than Firefox 2. Then Firefox 3 shipped faster than Safari 3. We'll see what the ship dates for Safari 4 and Firefox 3.1 or whatever look like, but I suspect tat if things continue as they are each will be the fastest shipping stable thing at ship time.
Is the 10% number a fraction of total solar output? Or of the output in the frequency ranges that the cells absorb? Note that the claim is that the new cells absorb in a much wider (and higher-energy) frequency range.
Not that there couldn't be a mistake in the article too.;)
Which one? There have been several (at least 3, possibly 5, depending on who's doing the counting). For what it's worth the most commonly accepted one is not the one the guy asking that question was thinking about.
I'd rather have someone who will honestly say "I don't know" when asked a question with no answer than someone who'll try to bullshit it, as long as we're talking about ethics and character.
There are two things people do with web browsers. One is loading and rendering web pages, and you're correct that there is more than JS performance to this, and in fact JS performance is a very minor part of it. The IE8 folks have a nice blog post about this.
The other thing people do is run web apps: gmail, google maps, zimbra, and so forth. Here, it turns out that JS performance is critical, since all the app logic is in JS. DOM performance also matters. Pure rendering is a bit less important, since the web apps don't tend to have a lot of the things that make rendering slow (e.g. having megabytes of text).
The focus on JS and DOM performance is basically an attempt on the part of all the players except IE in the browser space to make sure that web apps continue being delivered using existing (or new, as needed) open technologies that are not controlled by any one entity. The alternative is a universe of Flash (we're already a bit too close to that) or Silverlight.
The difference is that the new implementation actually moves the page over instead of loading it in the new window and closing the old tab. Try dragging a gmail message you're in the middle of composing in Firefox 3.0.1, and watch it lose the composition state. Firefox 3.1 won't.
Oddly enough, a lot of the memory and speed issues on Linux are in system libraries. For example, the GTK1 builds of mozilla (back when they existed) were a lot faster UI-wise than the GTK2 builds. This is true of all the other applications I've tried too: GTK2 is a bloaty, resource-hogging, and laggy.
Similar issues with Render (which affects graphics rendering via cairo). And there doesn't seem to be much interest in fixing this issue by anything short of a drastic rewrite of the acceleration architecture in Xorg. Just taking simple fixes that would fix basic issues like image scaling being slower using Render than doing it client-side is below the dignity of the Xorg developers, apparently.
Then there's pango, which is "really fast if you use it right" and apparently everyone is just using it wrong. It also has a whole slew of one-time leaks (allocates memory once at startup and never releases it) which make it more or less impossible to spot recurring memory leaks (much more serious) in all the noise.
Last of all, I'm not sure what your last sentence means. is supported cross-platform. So is every single other feature listed in the alpha 2 release notes as far as I can tell. Tracemonkey is happening cross-platform (at least independent of OS; it _is_ processor-dependent since it has to generate machine code, and at the moment only works on i386, x86-64, and ARM). So what's the "don't actually apply to the Mac and Linux versions" thing you're talking about?
> The problem of course is all of the complexity moves to software rather than the hardware.
Not only that, but the result also ends up slower. Turing's theorem doesn't have anything to say about how _long_ things take, only that they eventually happen.
The XUL framework doesn't alter our processing and memory requirements. The XUL is interpreted at specific points, it's not something that needs to be resident in memory the entire time the browser is running. (and correctly, it isn't). It's not even a factor in the average resources consumed by the browser.
That's actually flat-out wrong. The XUL is parsed once, more or less, but then for every new window you instantiate a DOM tree based on the XUL prototypes. Then you create a layout tree to actually paint the stuff. There's a fair amount of processing and memory requirements there. And yes, this is all resident in memory all the time.
I agree that it's not a huge factor in overall memory consumption, but that's because a typical "modern" page DOM (things like the Google front page excluded) has about 3-4x as many DOM nodes as the Firefox UI (which has about 2500). And if you're using multiple tabs, that's only 15-20 extra DOM nodes per tab, which is dwarfed by the page inside, of course. So it's not a huge factor, but it's certainly a factor. And it's definitely a factor for performance (Gecko without the Firefox UI is about 20% faster at loading pages last I checked; people are trying to hunt down the sources of the difference and eliminate them, but they're not there yet).
you need code to be refactored, which isn't happening right now.
It actually is....
Note also that oftentimes reducing memory consumption means a performance hit and vice versa. This goes for both code-generation by the compiler and for the various data structures used. It's very rare that you can significantly reduce both.
> but Mozilla are still using a Gecko that has changed little in years apart from tweaking
It's interesting that you say this, given that there was a pretty significant rewrite of large parts of the layout subset of Gecko between Firefox 2 and Firefox 3, and that there are other major changes that happened in the Firefox 3 timeframe and are happening now.
Are you sure you aren't thinking of the period from about 2001 to about 2005 when there was pretty much no one working full-time on Gecko (back when there were about 10 full-time people in the Mozilla project in general, after AOL got rid of the Netscape division)?
Slashdot Mirror
Javascript can't set the value of the file element. So it can only send files that you explicitly pick with the filepicker back to the server.
> JavaScript methods, or DOM methods called from JavaScript?
For what it's worth, the former as often as the latter. Things like indirect eval, for example, used to be allowed in SpiderMonkey and now aren't.
Faster in what sense? In addition to the "how long does it take the benchmark" number there is the "how long does it take to start up" number and the "how much memory does it use" number. Last I checked the JVMs weren't so hot on the latter two no matter how they did on the former.
These projects aren't using each other's code, really. Not for the JS engine.
And all three JS engines are under licenses that would allow Microsoft to use them if so desired (BSD, BSD/LGPL and MPL/GPL/LGPL).
I meant a particular subtest of the benchmarks. The better benchmarks aim to have a variety of tests that exercise as much of the engine's functionality as possible.
Yep. Sunspider is a pure JS benchmark, no DOM.
By the way, expect Firefox 3.1 to have faster DOM access than Firefox 3. It's being pretty actively worked on.
You're assuming that "V8" and "Tracemonkey" (and "SFX", for that matter) are frozen entities. They happen to be in active (furious, really) development, so the relative speeds change daily if not more often. Especially if you pick a particular test.
Are you running the standard Firefox nightlies? Or the actual branch active tracemonkey development is happening on?
See my other post on this article about measurement bias if one measures right after landing big changes. ;)
Bingo. What it comes down to is that the answer to "Is X faster than Y" will depend on two things:
1) The benchmark
2) The day of the week (or the exact, to the minute builds you're testing, if you prefer)
The reason for the latter is that all three are in active development. Each one is doing measurements right after landing major changes, against whatever the current state of the other two is. That means that there is inherent bias there in favor of whoever is doing the measurements being fastest: they've just hopped a step up in performance while the other two engines are on the same step they were at 3 minutes ago.
The same thing will happen with stable releases, for what it's worth. Safari 3 shipped a faster JS engine than Firefox 2. Then Firefox 3 shipped faster than Safari 3. We'll see what the ship dates for Safari 4 and Firefox 3.1 or whatever look like, but I suspect tat if things continue as they are each will be the fastest shipping stable thing at ship time.
Which is more or less what you said, I guess. ;)
There's a fair amount of UI work involved in running well on a small screen like that, though.
Is the 10% number a fraction of total solar output? Or of the output in the frequency ranges that the cells absorb? Note that the claim is that the new cells absorb in a much wider (and higher-energy) frequency range.
Not that there couldn't be a mistake in the article too. ;)
> who doesn't know what the Bush doctrine is
Which one? There have been several (at least 3, possibly 5, depending on who's doing the counting). For what it's worth the most commonly accepted one is not the one the guy asking that question was thinking about.
I'd rather have someone who will honestly say "I don't know" when asked a question with no answer than someone who'll try to bullshit it, as long as we're talking about ethics and character.
mkdir /tmp/guest_profile /tmp/guest_profile
firefox -profile
Or the equivalent on Mac and Windows. It should be pretty simple to set up a desktop icon that does the above.
IE8 betas have process-per-tab as well.
You're testing in 3.1 alpha 2? The behavior you describe is the one Firefox 3.0.x and earlier has, and is exactly what got fixed for 3.1.
The old code does work for POST data that's still in your cache, but you're right: the new one is closer to tab reparenting.
Right on target. And that's what the new implementation does.
It's been done (except without v8). See http://www.masonchang.com/2008/08/tracemonkey-vs-squirrelfish.html and note that it's not the end of the story for either engine: both are getting faster daily.
There are two things people do with web browsers. One is loading and rendering web pages, and you're correct that there is more than JS performance to this, and in fact JS performance is a very minor part of it. The IE8 folks have a nice blog post about this.
The other thing people do is run web apps: gmail, google maps, zimbra, and so forth. Here, it turns out that JS performance is critical, since all the app logic is in JS. DOM performance also matters. Pure rendering is a bit less important, since the web apps don't tend to have a lot of the things that make rendering slow (e.g. having megabytes of text).
The focus on JS and DOM performance is basically an attempt on the part of all the players except IE in the browser space to make sure that web apps continue being delivered using existing (or new, as needed) open technologies that are not controlled by any one entity. The alternative is a universe of Flash (we're already a bit too close to that) or Silverlight.
The difference is that the new implementation actually moves the page over instead of loading it in the new window and closing the old tab. Try dragging a gmail message you're in the middle of composing in Firefox 3.0.1, and watch it lose the composition state. Firefox 3.1 won't.
Oddly enough, a lot of the memory and speed issues on Linux are in system libraries. For example, the GTK1 builds of mozilla (back when they existed) were a lot faster UI-wise than the GTK2 builds. This is true of all the other applications I've tried too: GTK2 is a bloaty, resource-hogging, and laggy.
Similar issues with Render (which affects graphics rendering via cairo). And there doesn't seem to be much interest in fixing this issue by anything short of a drastic rewrite of the acceleration architecture in Xorg. Just taking simple fixes that would fix basic issues like image scaling being slower using Render than doing it client-side is below the dignity of the Xorg developers, apparently.
Then there's pango, which is "really fast if you use it right" and apparently everyone is just using it wrong. It also has a whole slew of one-time leaks (allocates memory once at startup and never releases it) which make it more or less impossible to spot recurring memory leaks (much more serious) in all the noise.
Last of all, I'm not sure what your last sentence means. is supported cross-platform. So is every single other feature listed in the alpha 2 release notes as far as I can tell. Tracemonkey is happening cross-platform (at least independent of OS; it _is_ processor-dependent since it has to generate machine code, and at the moment only works on i386, x86-64, and ARM). So what's the "don't actually apply to the Mac and Linux versions" thing you're talking about?
> The problem of course is all of the complexity moves to software rather than the hardware.
Not only that, but the result also ends up slower. Turing's theorem doesn't have anything to say about how _long_ things take, only that they eventually happen.
Fully agreed with the rest of what you say.
The XUL framework doesn't alter our processing and memory requirements. The XUL is interpreted at specific points, it's not something that needs to be resident in memory the entire time the browser is running. (and correctly, it isn't). It's not even a factor in the average resources consumed by the browser.
That's actually flat-out wrong. The XUL is parsed once, more or less, but then for every new window you instantiate a DOM tree based on the XUL prototypes. Then you create a layout tree to actually paint the stuff. There's a fair amount of processing and memory requirements there. And yes, this is all resident in memory all the time.
I agree that it's not a huge factor in overall memory consumption, but that's because a typical "modern" page DOM (things like the Google front page excluded) has about 3-4x as many DOM nodes as the Firefox UI (which has about 2500). And if you're using multiple tabs, that's only 15-20 extra DOM nodes per tab, which is dwarfed by the page inside, of course. So it's not a huge factor, but it's certainly a factor. And it's definitely a factor for performance (Gecko without the Firefox UI is about 20% faster at loading pages last I checked; people are trying to hunt down the sources of the difference and eliminate them, but they're not there yet).
you need code to be refactored, which isn't happening right now.
It actually is....
Note also that oftentimes reducing memory consumption means a performance hit and vice versa. This goes for both code-generation by the compiler and for the various data structures used. It's very rare that you can significantly reduce both.
> Of all the firefox users out there, most run both addin's.
Not at all. In fact, fewer than 1% do, last I checked (for either one alone; the number using both is obviously no bigger).
> but Mozilla are still using a Gecko that has changed little in years apart from tweaking
It's interesting that you say this, given that there was a pretty significant rewrite of large parts of the layout subset of Gecko between Firefox 2 and Firefox 3, and that there are other major changes that happened in the Firefox 3 timeframe and are happening now.
Are you sure you aren't thinking of the period from about 2001 to about 2005 when there was pretty much no one working full-time on Gecko (back when there were about 10 full-time people in the Mozilla project in general, after AOL got rid of the Netscape division)?