This is not correct. Some parts of webkit are licenced BSD + LGPL. Some are LGPL-only. The latter is a more restrictive license than the MPL/GPL/LGPL trilicense Mozilla uses, so only code that falls under the former could be used in Mozilla internally. LGPL-only code could, of course, be used as a separate library.
That said, Gecko developers _do_ look at Webkit code, and vice versa, as far as I know.
> Anyone know why Javascript performance is repeatedly mouthed off as such a big deal?
Web applications, and direct competition between the web platform (JS, HTML5, , , etc) and Flash and Silverlight.
In other words, people suspect that "websites" being created now or in the next few years (not existing ones) will require such performance, and would rather they were created using the web platform and not other technologies. Hence "website" in quotes: I'm not sure a flash-only thing should be called that.
> The point is this says nothing about whether the same size increase would have been > possible in the new machine with a removable battery.
Looks pretty doubtful from the X-rays, but you're welcome to do the research yourself.
> Please explain why you think it's "hard to impossible" for a removable battery to be > "weirdly shaped". (Or even what's "weird" about the shape.)
Seriously, do some googling. The battery is wedge in around other components, basically.
> I'm saying their comparison is not valid
They really didn't change that much about the internal layout of the machine other than the battery, so it's not completely invalid. Again, I suggest doing some research if you really care about the issue.
The entire capacity increase is due to an increase in volume as far as I can see, yes. They changed the battery tech too, but that was to increase number of cycles the battery can handle, since it's not as easy to replace.
Well, the size comparison is correct; it's been verified independently by just x-raying the laptops. The new battery really is 40% bigger, and there is no way to have fit that battery in the old laptop. It's weirdly shaped (which is hard to impossible to do with a user-removable battery) and really does take advantage of just that much extra space.
Or were you blanket-accusing Apple of lying without having done your homework?
The 40% number comes from Apple's product announcement, and is a direct comparison of the battery size in the new 17" Macbook Pro to the battery size in their previous 17" Macbook Pro.
> For example, the amount of space used by the casing and connector on my cellphone > battery is miniscule.
I'm going to assume that you've actually opened up the battery to verify this, right? Do you mind posting the numbers for the casing and connector, on both the battery end and the phone end (note that there's extra material in the phone so that it doesn't just collapse when the battery is removed).
But on a more serious note, it really doesn't take much of a difference in linear dimensions to make a big difference in volume, especially if some of the linear dimensions are pretty small (e.g. the thickness of the battery).
Could be. Firefox was unusably slow for me as far as window opening and menu operations on my old machine (about 7 years old now), but maybe your processor or especially graphics card is enough better than mine that it's not being an issue for you. I certainly wasn't running a compositing window manager!
As far as performance focus, there's Tracemonkey, but there's also been a good bit of recent DOM performance work (quickstubs, caching JS wrappers in some native objects directly, various improvements to things like array-index notation getters on nodelists and so forth). A bunch of that should be in Gecko 1.9.1, but more DOM performance work is certainly planned.
There's also various performance work being planned on the painting end (e.g. actually making use of hardware-accelerated OpenGL for some operations that are currently handled in software, if possible). That's slightly longer-term, but considered a must as graphics hardware improves and as the set of graphics-intensive things the browser tries to do (SVG, CSS transforms, and so forth) grows.
There's some general layout rearchitecture happening that may or may not lead to performance improvements. At least in the short term. In the long term, it should hopefully make it easier to optimize some of the code without going insane from reading it.
Finally, there's various work going on to improve pageload performance on high-latency networks by trying to kick off network loads as soon as possible (speculative parsing falls in this bucket). Immediate applications are various cellphone-like setups as well as satellite connections, but going forward it'll help everywhere to some extent, since in some ways what matters is the relationship of latency and bandwidth. And on your typical broadband connection bandwidth is generally increasing while latency has some hard caps on how low it can get (things like the speed of light, say, modulo edge caching setups).
> If I hit CTRL-+ any given page rerenders in 1-2 seconds, tops.
Yeah. It's things like opening menus or opening a new window that I find unusably slow on Linux....
> If people already HAVE faster code, then get it in there.
Not only do people have faster code, the faster code is just a newer version of a library Render is _already_ using. The issues have to do with getting Xorg to update to the new library version and then getting said updated Xorg out to users via distributions. Both are mostly political issues as far as I can see; throwing people at them isn't likely to help.
Unless you're suggesting that people should get together and fork Xorg over this particular issue? That still doesn't help with the "get it to users" part, sadly, and has other overhead (like all the other parts of Xorg maintenance, which are a lot more complicated).
There is significant political pushback in the Linux community against applications attempting to work around bugs in system libraries by shipping their own better versions of the code.
So yes, cairo could work around Render by choosing to not use Render and doing things itself, but it would be the Wrong(TM) thing to do, so it's not being done.
I think that's moronic, especially in view of the way Xorg is being improved (or not), but that's the political reality.
Mozilla _used_ to have its own client-side rendering for a lot of this stuff before the (much hailed by the Linux community) switch to cairo. It got ripped out in favor of just assuming that cairo would do the right thing. The result is things like 2-4x performance regressions in image scaling performance.... but at least all the right code is being used and the Linux distros are happy.
No I'm not bitter about any of this, with my old slow hardware. Not at all.;)
PGO is still not enabled for Linux builds, because g++ with PGO enabled fails to actually compile the app...
On the other hand, the Windows build was faster even without PGO enabled on Windows. This same sort of test has been done several times over the years and the results are pretty consistent: Windows builds of Firefox (and Mozilla Suite before it) run faster under Wine than native Linux builds do.
Web _applications_, on the other hand, the story is very different. Initial pageload of gmail is not entirely I/O bound. Clicking the "compose" button in gmail is _entirely_ CPI-bound. All the JS and CSS is loaded by that point; it's just rearranging your DOM to show the composition view instead of the folder view.
This is what the speed contest is all about: web applications built on top of open standards instead of, say, Silverlight.
> I must assume that an automatic test script that repeatedly opened / closed a few hundred > windows mocking normal usage would repeatedly trigger this
There are scripts that run as part of the QA process that not only do this but throw all sorts of "malformed" content at the browser in the process..
For what it's worth Firefox starting with 3.0 uses jemalloc, not the system malloc, on both Windows and Linux.
This was particularly a win on Windows, where the system allocator was worse for the particular workload Firefox ends up being than the Linux system malloc.
PGO on Linux is not enabled yet, at least in part because g++ failed to actually compile the whole app with it enabled. It will likely need to be enabled piecemeal, on a per-module basis, which is a lot more time-consuming. Given the number of bugs that popped up even with Windows PGO (which worked a heck of a lot better out of the gate), the work to get Linux PGO going was put off for later...
I should note that fastcall in particular is a huge win in some areas (e.g. interpreters, where every instruction really does count for opcode dispatch).
> The chart says that GCC doesn't implement PGO yet, but currently it does.
Yes, but have you tried it? On the particular case of the JavaScript engine in Mozilla PGO using MSVC made a 10% speed difference. PGO with gcc made less than 3% difference from an already slower time.
> Wine still has to live on top of X and thus it would suffer from similar issues.
Not necessarily. In particular, it doesn't have to defer to Render for compositing effects (of course neither does cairo-on-gtk, but at the moment it does) and thus have to live with the old-and-slow software rendering fallbacks in Render...
The optimization flags on Linux for the mozilla.org Firefox builds are:
-Os -freorder-blocks -fno-reorder-functions
with -finline-limit=50 added in g++ 4.1.x and 4.2.x to work around -Os being broken in those versions.
If you got your build from somewhere else, you may want to talk to the people who built it to see what optimization flags they used; the exact values will depend on the configure options used and the Firefox version, because the default values have changed over time.
Note that about:buildconfig just shows the options passed to configure, not the flags passed to the compiler/linker. To map its output to what's passed to the compiler you need to look at configure.in and the relevant Makefile.in files.
1) The Microsoft C++ compiler producing smaller and faster code than g++. 2) The performance of X being terrible (the "accelerated" server-side codepath more often
than not do the same software rendering that Firefox could do itself, but using a much
older and slower version of the same library). Trying to get this fixed runs into a
lot of "we're working on rewriting the acceleration architecture for Xorg from scratch
and should have it working in several years" responses.
Note that there is no separate Linux team, nor separate Windows team. Almost all the code is identical across platforms, except for graphics, filesystem access, and places where we actually have to talk to the OS (networking, say). This last is handled by NSPR, and I'm not aware of substantive performance differences there.
On the other hand, the fact that MSVC produces faster code for the javascript engine is _very_ noticeable.
> but an interview, with direct quotes for example, is
Have you ever been interviewed by a newspaper? I have. My experience, and that of othrs I know who have been interviewed, is that newspaper reporters will take the things you said, copy and paste on a word-by-word level, mixing and matching answers to different questions, and then publish it.
It's even worse with online publications of various sorts, but my experiences above were with a "good" print newspaper about 10-ish years ago, before print reporting had deteriorated to quite where it is now.
Mind you, sometimes the newspapers will have things right. But for the most part, on issues I know something about, they bat no better than 30%. I have a hard time imagining they do better on things I don't know anything about; I just don't catch them.
Uh... You do realize that the Democrats are the party that's been at the behest of Hollywood and the RIAA much more than the Republicans? They have generally campaigned harder for copyright extensions and such...
Slashdot Mirror
> In fact, webkit is licensed under BSD + GPL
This is not correct. Some parts of webkit are licenced BSD + LGPL. Some are LGPL-only. The latter is a more restrictive license than the MPL/GPL/LGPL trilicense Mozilla uses, so only code that falls under the former could be used in Mozilla internally. LGPL-only code could, of course, be used as a separate library.
That said, Gecko developers _do_ look at Webkit code, and vice versa, as far as I know.
> Anyone know why Javascript performance is repeatedly mouthed off as such a big deal?
Web applications, and direct competition between the web platform (JS, HTML5, , , etc) and Flash and Silverlight.
In other words, people suspect that "websites" being created now or in the next few years (not existing ones) will require such performance, and would rather they were created using the web platform and not other technologies. Hence "website" in quotes: I'm not sure a flash-only thing should be called that.
> Links to these X-Rays ?
Don't have them offhand, sorry. They were linked from somewhere in the Slashdot comments on the initial announcement, as I recall.
> The point is this says nothing about whether the same size increase would have been
> possible in the new machine with a removable battery.
Looks pretty doubtful from the X-rays, but you're welcome to do the research yourself.
> Please explain why you think it's "hard to impossible" for a removable battery to be
> "weirdly shaped". (Or even what's "weird" about the shape.)
Seriously, do some googling. The battery is wedge in around other components, basically.
> I'm saying their comparison is not valid
They really didn't change that much about the internal layout of the machine other than the battery, so it's not completely invalid. Again, I suggest doing some research if you really care about the issue.
The entire capacity increase is due to an increase in volume as far as I can see, yes. They changed the battery tech too, but that was to increase number of cycles the battery can handle, since it's not as easy to replace.
The new machine is more rigid than the old one.
Well, the size comparison is correct; it's been verified independently by just x-raying the laptops. The new battery really is 40% bigger, and there is no way to have fit that battery in the old laptop. It's weirdly shaped (which is hard to impossible to do with a user-removable battery) and really does take advantage of just that much extra space.
Or were you blanket-accusing Apple of lying without having done your homework?
The 40% number comes from Apple's product announcement, and is a direct comparison of the battery size in the new 17" Macbook Pro to the battery size in their previous 17" Macbook Pro.
> For example, the amount of space used by the casing and connector on my cellphone
> battery is miniscule.
I'm going to assume that you've actually opened up the battery to verify this, right? Do you mind posting the numbers for the casing and connector, on both the battery end and the phone end (note that there's extra material in the phone so that it doesn't just collapse when the battery is removed).
But on a more serious note, it really doesn't take much of a difference in linear dimensions to make a big difference in volume, especially if some of the linear dimensions are pretty small (e.g. the thickness of the battery).
Could be. Firefox was unusably slow for me as far as window opening and menu operations on my old machine (about 7 years old now), but maybe your processor or especially graphics card is enough better than mine that it's not being an issue for you. I certainly wasn't running a compositing window manager!
Yeah, that all looks about right to me.
As far as performance focus, there's Tracemonkey, but there's also been a good bit of recent DOM performance work (quickstubs, caching JS wrappers in some native objects directly, various improvements to things like array-index notation getters on nodelists and so forth). A bunch of that should be in Gecko 1.9.1, but more DOM performance work is certainly planned.
There's also various performance work being planned on the painting end (e.g. actually making use of hardware-accelerated OpenGL for some operations that are currently handled in software, if possible). That's slightly longer-term, but considered a must as graphics hardware improves and as the set of graphics-intensive things the browser tries to do (SVG, CSS transforms, and so forth) grows.
There's some general layout rearchitecture happening that may or may not lead to performance improvements. At least in the short term. In the long term, it should hopefully make it easier to optimize some of the code without going insane from reading it.
Finally, there's various work going on to improve pageload performance on high-latency networks by trying to kick off network loads as soon as possible (speculative parsing falls in this bucket). Immediate applications are various cellphone-like setups as well as satellite connections, but going forward it'll help everywhere to some extent, since in some ways what matters is the relationship of latency and bandwidth. And on your typical broadband connection bandwidth is generally increasing while latency has some hard caps on how low it can get (things like the speed of light, say, modulo edge caching setups).
> If I hit CTRL-+ any given page rerenders in 1-2 seconds, tops.
Yeah. It's things like opening menus or opening a new window that I find unusably slow on Linux....
> If people already HAVE faster code, then get it in there.
Not only do people have faster code, the faster code is just a newer version of a library Render is _already_ using. The issues have to do with getting Xorg to update to the new library version and then getting said updated Xorg out to users via distributions. Both are mostly political issues as far as I can see; throwing people at them isn't likely to help.
Unless you're suggesting that people should get together and fork Xorg over this particular issue? That still doesn't help with the "get it to users" part, sadly, and has other overhead (like all the other parts of Xorg maintenance, which are a lot more complicated).
There is significant political pushback in the Linux community against applications attempting to work around bugs in system libraries by shipping their own better versions of the code.
So yes, cairo could work around Render by choosing to not use Render and doing things itself, but it would be the Wrong(TM) thing to do, so it's not being done.
I think that's moronic, especially in view of the way Xorg is being improved (or not), but that's the political reality.
Mozilla _used_ to have its own client-side rendering for a lot of this stuff before the (much hailed by the Linux community) switch to cairo. It got ripped out in favor of just assuming that cairo would do the right thing. The result is things like 2-4x performance regressions in image scaling performance.... but at least all the right code is being used and the Linux distros are happy.
No I'm not bitter about any of this, with my old slow hardware. Not at all. ;)
> it's undoubtedly because Firefox's code is optimized for Windows, rather than Linux.
With the exception of PGO not being used on Linux yet, that statement would happen to be false.
And the Windows build was faster under Wine than the native Linux build even before PGO on Windows happened.
PGO is still not enabled for Linux builds, because g++ with PGO enabled fails to actually compile the app...
On the other hand, the Windows build was faster even without PGO enabled on Windows. This same sort of test has been done several times over the years and the results are pretty consistent: Windows builds of Firefox (and Mozilla Suite before it) run faster under Wine than native Linux builds do.
Web pages, you're more or less right.
Web _applications_, on the other hand, the story is very different. Initial pageload of gmail is not entirely I/O bound. Clicking the "compose" button in gmail is _entirely_ CPI-bound. All the JS and CSS is loaded by that point; it's just rearranging your DOM to show the composition view instead of the folder view.
This is what the speed contest is all about: web applications built on top of open standards instead of, say, Silverlight.
> I must assume that an automatic test script that repeatedly opened / closed a few hundred
> windows mocking normal usage would repeatedly trigger this
There are scripts that run as part of the QA process that not only do this but throw all sorts of "malformed" content at the browser in the process..
For what it's worth Firefox starting with 3.0 uses jemalloc, not the system malloc, on both Windows and Linux.
This was particularly a win on Windows, where the system allocator was worse for the particular workload Firefox ends up being than the Linux system malloc.
PGO on Linux is not enabled yet, at least in part because g++ failed to actually compile the whole app with it enabled. It will likely need to be enabled piecemeal, on a per-module basis, which is a lot more time-consuming. Given the number of bugs that popped up even with Windows PGO (which worked a heck of a lot better out of the gate), the work to get Linux PGO going was put off for later...
I should note that fastcall in particular is a huge win in some areas (e.g. interpreters, where every instruction really does count for opcode dispatch).
> The chart says that GCC doesn't implement PGO yet, but currently it does.
Yes, but have you tried it? On the particular case of the JavaScript engine in Mozilla PGO using MSVC made a 10% speed difference. PGO with gcc made less than 3% difference from an already slower time.
> Wine still has to live on top of X and thus it would suffer from similar issues.
Not necessarily. In particular, it doesn't have to defer to Render for compositing effects (of course neither does cairo-on-gtk, but at the moment it does) and thus have to live with the old-and-slow software rendering fallbacks in Render...
The optimization flags on Linux for the mozilla.org Firefox builds are:
-Os -freorder-blocks -fno-reorder-functions
with -finline-limit=50 added in g++ 4.1.x and 4.2.x to work around -Os being broken in those versions.
If you got your build from somewhere else, you may want to talk to the people who built it to see what optimization flags they used; the exact values will depend on the configure options used and the Firefox version, because the default values have changed over time.
Note that about:buildconfig just shows the options passed to configure, not the flags passed to the compiler/linker. To map its output to what's passed to the compiler you need to look at configure.in and the relevant Makefile.in files.
Actually, the difference has more to do with:
1) The Microsoft C++ compiler producing smaller and faster code than g++.
2) The performance of X being terrible (the "accelerated" server-side codepath more often
than not do the same software rendering that Firefox could do itself, but using a much
older and slower version of the same library). Trying to get this fixed runs into a
lot of "we're working on rewriting the acceleration architecture for Xorg from scratch
and should have it working in several years" responses.
Note that there is no separate Linux team, nor separate Windows team. Almost all the code is identical across platforms, except for graphics, filesystem access, and places where we actually have to talk to the OS (networking, say). This last is handled by NSPR, and I'm not aware of substantive performance differences there.
On the other hand, the fact that MSVC produces faster code for the javascript engine is _very_ noticeable.
> but an interview, with direct quotes for example, is
Have you ever been interviewed by a newspaper? I have. My experience, and that of othrs I know who have been interviewed, is that newspaper reporters will take the things you said, copy and paste on a word-by-word level, mixing and matching answers to different questions, and then publish it.
It's even worse with online publications of various sorts, but my experiences above were with a "good" print newspaper about 10-ish years ago, before print reporting had deteriorated to quite where it is now.
Mind you, sometimes the newspapers will have things right. But for the most part, on issues I know something about, they bat no better than 30%. I have a hard time imagining they do better on things I don't know anything about; I just don't catch them.
Isn't this just a variant of the "If you're not doing something illegal, you have nothing to hide" argument?
Are you seriously asserting that one's medical history cannot be used for blackmail purposes, if nothing else?
Uh... You do realize that the Democrats are the party that's been at the behest of Hollywood and the RIAA much more than the Republicans? They have generally campaigned harder for copyright extensions and such...