Sounds good. With any luck firefox-after-3.6 will have plug-ins running in a separate process, so at that point the memory blame will be easier to assign...
> Well, FWIW, for the project I was working on, FF was too slow to be acceptable > for public use.
Totally believable. If you can manage to extract enough script to file a bug on (that is, make that part of the script public), that would be great. If not, I absolutely understand how that goes.
> it seems to me that the actual rendering of the browser window isn't the bottleneck
It really depends. It's a bottleneck for scrolling. It's a bottleneck any time interesting graphical effects (transforms, opacity, svg, etc) are being used. In Gecko's case, it's not uncommon to have the actual painting taking 30+% of the user-perceived time. From my profiling of webkit nightlies, the numbers are similar there. Things are even worse for video (e.g. for full-screen video color-space conversion is one of the main bottlenecks!).
I believe all the browser vendors are looking at making serious use of hardware-accelerated rendering at this point; it's the only way to get acceptable performance on some of the graphical effects people are using more and more.
> Two things surprised me here. One is that Chrome and Safari are 3x faster than FF
There are a few things going on here:
1) The public sunspider benchmark has a bug in that it uses a Spidermonkey-specific
extension in one of the tests that slows it down in Firefox only. Apple has fixes the
bug in their revision control system but is refusing to push the fix out to the public
site. 2) Chrome and Safari are in fact faster on sunspider than Firefox. Firefox is up to 5x
faster on other JS benchmarks. Depending on exactly what you're doing, you might have
better performance with one or the other.
No, "components"is very much not plug-ins. Plug-ins are binary object files that are loaded by the browser and interact with the browser via NPAPI. Components are either JavaScript or binary object files that interact with the browser via XPCOM. See https://developer.mozilla.org/en/Creating_XPCOM_Components for details.
A major difference is that NPAPI is a restricted API which allows plug-ins to make certain requests of the browser (and vice versa), while XPCOM is the internal object model of the browser and allows access to most of the browser objects (including direct access to the internal layout data structures in some cases, for binary components).
Another major difference is that NPAPI has a backwards-compatible ABI, while XPCOM in general does NOT. In particular, the ABI changes in various ways with every Gecko version, and a binary XPCOM component compiled against one Gecko version will almost certainly crash if run against a different one, unless it takes some not-that-trivial precautions to avoid that.
This last is the reason for the components white-list: a number of apps have been tossing binary object XPCOM components into the Firefox install directory, and as Firefox got more popular there have been more and more of these. The old behavior was to load the components from that directory (on the possibly-naive assumption that it's the Firefox install directory and hence components in there are part of Firefox). This caused serious problems when users started upgrading from Firefox 3.0 to Firefox 3.5, because suddenly components compiled against Gecko 1.9.0 were running against Gecko 1.9.1... and by and large crashing. Since it looks like convincing other software vendors to not mess with your install directory is not likely, the alternative approach of hardcoding the list of components to load was taken.
Someone who wants to install a binary XPCOM component can continue to do so in an extension, with the major difference there being that extensions have version compatibility checks performed; an extension that only claims to be compatible with Firefox 3.0 won't be loaded by Firefox 3.5.
> they should have an "approved" list within the browser's data
That's precisely what this fix does.
> as opposed to a "disabled" one
I have no idea why you decided there's such a list. Was it something in the article?
That's assuming you're talking about component loading, not add-ons; from the latter part of your comment it sounds like you're talking about add-ons...
I hope if you're implementing strings in a programming language then you think about how they will typically be used in the domain your language is addressing. Are large strings going to be common? Will indexing (something ropes are significantly worse at) be common? Will there be substring searches performed on the strings? Regular expression matches?
It's no use having better order-of-growth if in practice your N is small and your constant factor huge....
Gecko's memory usage now is less than it was in the early 2000s in many cases. So this particular program is actually using less memory than it was in the early 2000s. Since just the shared libraries for it are bigger than 32MB (uncompressed, on some OSes, etc), it's hard to see how it could fit in 32MB of RAM...
If your question is why there are these big shared libraries, the answer is that it's trying to do too much. The SVG1.1 spec is about 800 pages last I checked. And this is not because it goes into excruciating detail or anything. The CSS2.1 spec is about 300 pages (and while it's better on the detail, it's not perfect). You just end up with a huge gob of code to handle all those behaviors the huge specs require.
How much memory do you think a web browser handling modern web standards should take up? How does that number stack up against existing web browsers?
There's also the data set. People think nothing of sending hundreds of kilobytes of JS per page to the browser (last I checked, cnn.com has upwards of 500KB of JS just linked directly from the page; who knows whether they load more?). People think nothing of sending large amounts of graphics, etc.
Which brings us to the last point: programs are bigger because they _can_ be. If you have to fit into 32MB of RAM, then you can't just decode a 3000px by 3000px image into memory (it's be 4 * 3000 * 3000 bytes, or 36MB). You do it piece by piece and forget the pieces after painting them, or something. You don't even cache decoded smaller images, since it's so easy for that to fill up memory. If you feel like you have more ram to work with, you might make the space/performance tradeoff of keeping the decoded image in memory instead of decoding on every paint...
> I haven't seen a HTML 5 page with a video i want to keep to try pulling it out, but I > believe someone will come along and make a one click solution to this
You mean like the "save video" option in the Firefox context menu for tags?
Given that most of the time Flash _is_ embedded using (typically inside an IE-only ), I can't figure our what the second part of your question is asking.
The tag is better than for video purposes because it gives both the website author and the browser more flexibility (telling the browser this is a video, allowing the author to easily provide the video in multiple codecs, etc). All of this _could_ be done via and a sufficiently good video-playing plug-in, but that just brings us back to Flash.
Note that Flash has lower platform penetration (in the sense of platforms that it's available on) than -supporting browsers do, last I checked.
Spidermonkey (the ECMAScript implementation in Gecko, hence in Firefox) and Nitro (aka SFX Extreme, the ECMAScript implementation in Safari) both use JITs as well.
> just like modern Java runtimes
Not quite; the tradeoffs are somewhat different.
> JavaScript is going to approach native code speed
Firefox has never silently pushed major updates. It has prompted for major updates, but the user has always had to choose to install it. It does silently install minor (security) updates by default.
Safari uses the same updating mechanism as on Mac: the update window comes up and asks whether you want to update it (as well as iTunes, etc), with all of them preselected if you decide to click ok. Again, pretty simple to say "no" to. I think nowadays it even differentiates between major and minor updates.
So it's ok to mock someone whom you've stereotyped as being "like those in power" until you discover that they are not in fact like them for some reason?
Cut out the double standards; mocking people is no good no matter what. But a lot of what the PC crowd wants to silence isn't exactly "mocking".
> For a healthy field, that chart should look like a bell curve with "just right" salary > being the peak of the curve.
This is true if "field" is narrow enough that most people fitting the description are somewhat comparable.
"lawyer" is broad enough, with enough sub-specialization, that I don't think one would expect a single bell curve out of it. I'm a little surprised that the distribution was just bimodal.
I'd similarly expect multimodal results for "doctor" or "engineer", for that matter.
> There is no sales tax unless you are in the same state as Amazon, unlike VAT.
True, but doesn't matter much for the point of the argument, since the US list price doesn't include the sales tax no matter what, and the article is comparing list prices.
> Done singly you could get away without charging VAT, but I imagine customs would notice > after awhile.
The whole point of the article is that the UK list price is 40% more than the US list price.
> The US price is the US price including their profit.
Right.
> It's not like they have to buy any more copies to sell in the EU.
That depends on the licensing terms.
Also, the operating expenses (e.g. the data connection for the kindle) remain and might not be priced the same in the EU.
> Sales tax in the US is VAT in the EU.
Sort of, except that the list price (which is what the article is about) includes the VAT and doesn't include sales tax. And there are more differences in the details (see below).
> Wouldn't surprise me if they just added more on for the hell of it.
Sure could be! It's just hard to say without going through their costs in detail, and the _definitely_ didn't add on 40%.
> Plus you don't pay vat on second hand goods
This is true if the original good had the VAT paid on it. However, if the good was bought outside the country (or the EU, in the EU case) and then imported, VAT is owed at the moment of import (unlike sales tax, which is owed at the moment of purchase only). The whole point of a VAT is that it only gets charged once (unlike sales tax, which is why VAT rates are higher), but it DOES get charged. Note that it also typically gets refunded if you export the good after purchasing (again, unlike a sales tax).
Put that way, nothing except the fact that it's likely to not be profitable. Given a US price P (always excluding sales tax) and a VAT of 15-25% depending on the EU country (applies to e-books in most of them; must typically be included in the price by law) you have to charge somewhere between 1.15*P and 1.25*P just to break even.
So 10% markup in the list price would be a loss. 20% would be about break-even, if we assume a 20% VAT. A 10% increase in what the seller gets would mean a 32% markup in the list price given that same 20% VAT.
Now they are viewed as some sort of "this person can function minimally" stamp. That's how high school used to be viewed. Basically, people assume that if someone doesn't have a college degree it's because they couldn't get one, and given the amount to which college degrees have been watered down and the extent to which kids are pushed to go to college, if someone couldn't get one the assumption becomes that something is wrong with them.
This is, needless to say, a stupid system. At least the "high school degree == person can read and write" view had a simple solution for cases where someone could read and write but didn't want to deal with the hamster wheels: a GED. There's no equivalent for your average no-real-skills college undergrad degree, and hence no avoiding the (expensive) I-need-the-piece-of-paper hamster wheel.
Slashdot Mirror
Last I checked, there were about 200k-300k Firefox nightly users. Microsoft has around 90k employees as of 2008 (worldwide).
So unlikely, but at least possibly similar ballpark if every single MS employee uses the IE nightlies (again, unlikely).
Sounds good. With any luck firefox-after-3.6 will have plug-ins running in a separate process, so at that point the memory blame will be easier to assign...
> Well, FWIW, for the project I was working on, FF was too slow to be acceptable
> for public use.
Totally believable. If you can manage to extract enough script to file a bug on (that is, make that part of the script public), that would be great. If not, I absolutely understand how that goes.
> it seems to me that the actual rendering of the browser window isn't the bottleneck
It really depends. It's a bottleneck for scrolling. It's a bottleneck any time interesting graphical effects (transforms, opacity, svg, etc) are being used. In Gecko's case, it's not uncommon to have the actual painting taking 30+% of the user-perceived time. From my profiling of webkit nightlies, the numbers are similar there. Things are even worse for video (e.g. for full-screen video color-space conversion is one of the main bottlenecks!).
I believe all the browser vendors are looking at making serious use of hardware-accelerated rendering at this point; it's the only way to get acceptable performance on some of the graphical effects people are using more and more.
Are there particular sites that trigger this? If so, can you please file a bug and cc ":bz" on it?
> Two things surprised me here. One is that Chrome and Safari are 3x faster than FF
There are a few things going on here:
1) The public sunspider benchmark has a bug in that it uses a Spidermonkey-specific
extension in one of the tests that slows it down in Firefox only. Apple has fixes the
bug in their revision control system but is refusing to push the fix out to the public
site.
2) Chrome and Safari are in fact faster on sunspider than Firefox. Firefox is up to 5x
faster on other JS benchmarks. Depending on exactly what you're doing, you might have
better performance with one or the other.
> "Components" = plugins.
No, "components"is very much not plug-ins. Plug-ins are binary object files that are loaded by the browser and interact with the browser via NPAPI. Components are either JavaScript or binary object files that interact with the browser via XPCOM. See https://developer.mozilla.org/en/Creating_XPCOM_Components for details.
A major difference is that NPAPI is a restricted API which allows plug-ins to make certain requests of the browser (and vice versa), while XPCOM is the internal object model of the browser and allows access to most of the browser objects (including direct access to the internal layout data structures in some cases, for binary components).
Another major difference is that NPAPI has a backwards-compatible ABI, while XPCOM in general does NOT. In particular, the ABI changes in various ways with every Gecko version, and a binary XPCOM component compiled against one Gecko version will almost certainly crash if run against a different one, unless it takes some not-that-trivial precautions to avoid that.
This last is the reason for the components white-list: a number of apps have been tossing binary object XPCOM components into the Firefox install directory, and as Firefox got more popular there have been more and more of these. The old behavior was to load the components from that directory (on the possibly-naive assumption that it's the Firefox install directory and hence components in there are part of Firefox). This caused serious problems when users started upgrading from Firefox 3.0 to Firefox 3.5, because suddenly components compiled against Gecko 1.9.0 were running against Gecko 1.9.1 ... and by and large crashing. Since it looks like convincing other software vendors to not mess with your install directory is not likely, the alternative approach of hardcoding the list of components to load was taken.
Someone who wants to install a binary XPCOM component can continue to do so in an extension, with the major difference there being that extensions have version compatibility checks performed; an extension that only claims to be compatible with Firefox 3.0 won't be loaded by Firefox 3.5.
Hope that makes things clearer.
Right, for add-ons there's a blacklist of add-ons that are ignored even if installed. By default add-ons are not installed, of course.
For components there's a whitelist of which ones will be loaded.
This slashdot article is about the latter, not the former.
> they should have an "approved" list within the browser's data
That's precisely what this fix does.
> as opposed to a "disabled" one
I have no idea why you decided there's such a list. Was it something in the article?
That's assuming you're talking about component loading, not add-ons; from the latter part of your comment it sounds like you're talking about add-ons...
I hope if you're implementing strings in a programming language then you think about how they will typically be used in the domain your language is addressing. Are large strings going to be common? Will indexing (something ropes are significantly worse at) be common? Will there be substring searches performed on the strings? Regular expression matches?
It's no use having better order-of-growth if in practice your N is small and your constant factor huge....
Gecko's memory usage now is less than it was in the early 2000s in many cases. So this particular program is actually using less memory than it was in the early 2000s. Since just the shared libraries for it are bigger than 32MB (uncompressed, on some OSes, etc), it's hard to see how it could fit in 32MB of RAM...
If your question is why there are these big shared libraries, the answer is that it's trying to do too much. The SVG1.1 spec is about 800 pages last I checked. And this is not because it goes into excruciating detail or anything. The CSS2.1 spec is about 300 pages (and while it's better on the detail, it's not perfect). You just end up with a huge gob of code to handle all those behaviors the huge specs require.
How much memory do you think a web browser handling modern web standards should take up? How does that number stack up against existing web browsers?
There's also the data set. People think nothing of sending hundreds of kilobytes of JS per page to the browser (last I checked, cnn.com has upwards of 500KB of JS just linked directly from the page; who knows whether they load more?). People think nothing of sending large amounts of graphics, etc.
Which brings us to the last point: programs are bigger because they _can_ be. If you have to fit into 32MB of RAM, then you can't just decode a 3000px by 3000px image into memory (it's be 4 * 3000 * 3000 bytes, or 36MB). You do it piece by piece and forget the pieces after painting them, or something. You don't even cache decoded smaller images, since it's so easy for that to fill up memory. If you feel like you have more ram to work with, you might make the space/performance tradeoff of keeping the decoded image in memory instead of decoding on every paint...
Given that his claims about Mozilla are flat-out false, I doubt that he actually did.
> Is Mozilla actually participating in that nonsense?
No. I have no idea where Mr. Vixie got that misinformation, nor do I know why he's spreading it.
> I haven't seen a HTML 5 page with a video i want to keep to try pulling it out, but I
> believe someone will come along and make a one click solution to this
You mean like the "save video" option in the Firefox context menu for tags?
Given that most of the time Flash _is_ embedded using (typically inside an IE-only ), I can't figure our what the second part of your question is asking.
The tag is better than for video purposes because it gives both the website author and the browser more flexibility (telling the browser this is a video, allowing the author to easily provide the video in multiple codecs, etc). All of this _could_ be done via and a sufficiently good video-playing plug-in, but that just brings us back to Flash.
Note that Flash has lower platform penetration (in the sense of platforms that it's available on) than -supporting browsers do, last I checked.
Spidermonkey (the ECMAScript implementation in Gecko, hence in Firefox) and Nitro (aka SFX Extreme, the ECMAScript implementation in Safari) both use JITs as well.
> just like modern Java runtimes
Not quite; the tradeoffs are somewhat different.
> JavaScript is going to approach native code speed
Somewhat. Depends on your jit, on your code, etc.
Firefox has never silently pushed major updates. It has prompted for major updates, but the user has always had to choose to install it. It does silently install minor (security) updates by default.
Safari uses the same updating mechanism as on Mac: the update window comes up and asks whether you want to update it (as well as iTunes, etc), with all of them preselected if you decide to click ok. Again, pretty simple to say "no" to. I think nowadays it even differentiates between major and minor updates.
So it's ok to mock someone whom you've stereotyped as being "like those in power" until you discover that they are not in fact like them for some reason?
Cut out the double standards; mocking people is no good no matter what. But a lot of what the PC crowd wants to silence isn't exactly "mocking".
> or go to 64 bit and use 1/10000 of a second
We're talking about hardware and software designed and built in the 70s. Good luck with that 64 bit thing.
> For a healthy field, that chart should look like a bell curve with "just right" salary
> being the peak of the curve.
This is true if "field" is narrow enough that most people fitting the description are somewhat comparable.
"lawyer" is broad enough, with enough sub-specialization, that I don't think one would expect a single bell curve out of it. I'm a little surprised that the distribution was just bimodal.
I'd similarly expect multimodal results for "doctor" or "engineer", for that matter.
> There is no sales tax unless you are in the same state as Amazon, unlike VAT.
True, but doesn't matter much for the point of the argument, since the US list price doesn't include the sales tax no matter what, and the article is comparing list prices.
> Done singly you could get away without charging VAT, but I imagine customs would notice
> after awhile.
I'd think so. ;)
> What has the US price got to do with it ?
The whole point of the article is that the UK list price is 40% more than the US list price.
> The US price is the US price including their profit.
Right.
> It's not like they have to buy any more copies to sell in the EU.
That depends on the licensing terms.
Also, the operating expenses (e.g. the data connection for the kindle) remain and might not be priced the same in the EU.
> Sales tax in the US is VAT in the EU.
Sort of, except that the list price (which is what the article is about) includes the VAT and doesn't include sales tax. And there are more differences in the details (see below).
> Wouldn't surprise me if they just added more on for the hell of it.
Sure could be! It's just hard to say without going through their costs in detail, and the _definitely_ didn't add on 40%.
> Plus you don't pay vat on second hand goods
This is true if the original good had the VAT paid on it. However, if the good was bought outside the country (or the EU, in the EU case) and then imported, VAT is owed at the moment of import (unlike sales tax, which is owed at the moment of purchase only). The whole point of a VAT is that it only gets charged once (unlike sales tax, which is why VAT rates are higher), but it DOES get charged. Note that it also typically gets refunded if you export the good after purchasing (again, unlike a sales tax).
Put that way, nothing except the fact that it's likely to not be profitable. Given a US price P (always excluding sales tax) and a VAT of 15-25% depending on the EU country (applies to e-books in most of them; must typically be included in the price by law) you have to charge somewhere between 1.15*P and 1.25*P just to break even.
So 10% markup in the list price would be a loss. 20% would be about break-even, if we assume a 20% VAT. A 10% increase in what the seller gets would mean a 32% markup in the list price given that same 20% VAT.
If Microsoft contacted the Mozilla folks first and the OKed said blocking?
I'd certainly hope people wouldn't be angry in that situation, but as you point out reason is hard to come by.
They _used_ to be viewed this way.
Now they are viewed as some sort of "this person can function minimally" stamp. That's how high school used to be viewed. Basically, people assume that if someone doesn't have a college degree it's because they couldn't get one, and given the amount to which college degrees have been watered down and the extent to which kids are pushed to go to college, if someone couldn't get one the assumption becomes that something is wrong with them.
This is, needless to say, a stupid system. At least the "high school degree == person can read and write" view had a simple solution for cases where someone could read and write but didn't want to deal with the hamster wheels: a GED. There's no equivalent for your average no-real-skills college undergrad degree, and hence no avoiding the (expensive) I-need-the-piece-of-paper hamster wheel.