Extension compatibility hasn't been a problem since Firefox 10; the max version is now automatically bumped.
Furthermore, Firefox 4, 5, and 6 were kind of sucky releases, esp. in terms of memory consumption. Firefox 15 is a much better browser. UI changes since 5 have been minimal. It's also not full of security holes the way older versions now are. You should try it.
In practice we've found extremely few problems with "forcefully ripping" the memory away. In comparison, *many* add-ons no longer leak as a result. The cost:benefit ratio is massively favourable.
The real problem is page faults. People don't notice how much memory a program uses until/unless it starts causing page faults.
Some other observations and responses to this thread.
One reason that browsers are using more memory over time is that browers are way more capable than they used to be. HTML5, web apps and all that.
People say "I have N tabs open, Firefox is using M MB of memory". Often followed by "that seems outrageous" or "that seems reasonable". Without saying what those tabs have in them, it's pretty much useless.
Firefox's memory usage has varied over the years. FF2 was terrible, and contributed heavily to the bad reputation. FF3, FF3.5 and FF3.6 were much better. FF4 is worse than FF3.6; FF5 will be better (it already is). Subsequent Firefoxes will hopefully be better again.
It's global memory usage at the moment. I'm working on https://bugzilla.mozilla.org/show_bug.cgi?id=661474 which will give JS memory usage per "compartment", which roughly means "per domain". So if a page at foo.com has a Twitter feed and some Google Analytics stuff, there'll be three compartments, one for foo.com, one for twitter.com, and one for google-analytics.com. It's not quite per-tab, but in that direction. about:memory is evolving, keep an eye on it.
No: all general purpose tools can be used harmfully. A hammer can drive in nails or stave in someone's head.
But some tools are clearly designed with harmful intent in mind. There's a world of difference.
I thought the point of TRIPS was to make the chip do all the scheduling (ie the Data Flow architecture) rather than depend on the compiler generated sequence of instructions.
It's static placement, dynamic issue. So the compiler schedules
the instructions onto the ALU grid. But then the hardware issues the instructions when their inputs are ready.
A superscalar chip has dynamic placement and dynamic issue -- the hardware is responsible for deciding which ALU each instruction goes to, and when they get issued. Doing this well requires a lot of transistors and costs power, and the hardware is rediscovering inter-instruction dependencies that the compiler could have told it.
A VLIW chip has static placement and static issue -- the compiler is responsible for deciding which ALU each instruction goes to, and exactly when it gets issued. This is really hard to do well due to variable latencies of instructions, eg. due to cache misses. It puts too much of a responsibility onto the compiler.
TRIPS is static placement, dynamic issue. So the compiler schedules the instructions onto the ALU grid. But then the hardware issues the instructions when their inputs are ready.
It's intended to find a good middle ground between superscalar and VLIW in terms of what the hardware has to do, and what the compiler has to do.
What this is *not* in any form is a general purpose CPU. It won't boot linux, plain and simple. This is for doing stream data processing such as compression or HPC simulations.
Wrong. It is entirely general purpose. Although the prototype won't boot Linux -- the prototype TRIPS boards will run under the control of an embedded Linux on a PPC machine -- that is only being done to simplify the design of the prototype chip and so no OS has to be ported to it to make the thing work.
Slashdot Mirror
That's a common misconception. Fortunately I wrote https://blog.mozilla.org/nnethercote/2012/08/29/debunking-a-misconception-about-firefox-releases/ earlier today just for you.
I'm pretty sure there's a "ignore the warning just this time" option now.
Extension compatibility hasn't been a problem since Firefox 10; the max version is now automatically bumped. Furthermore, Firefox 4, 5, and 6 were kind of sucky releases, esp. in terms of memory consumption. Firefox 15 is a much better browser. UI changes since 5 have been minimal. It's also not full of security holes the way older versions now are. You should try it.
In practice we've found extremely few problems with "forcefully ripping" the memory away. In comparison, *many* add-ons no longer leak as a result. The cost:benefit ratio is massively favourable.
There's an option to turn it off. This is Firefox, which always has options for that sort of thing, unlike some other browsers.
Try it. Check out the user feedback near the bottom of https://blog.mozilla.org/nnethercote/2012/07/19/firefox-15-plugs-the-add-on-leaks/ -- people have experienced greatly reduced memory consumption, faster painting and scrolling, and fewer pauses.
One reason that browsers are using more memory over time is that browers are way more capable than they used to be. HTML5, web apps and all that.
People say "I have N tabs open, Firefox is using M MB of memory". Often followed by "that seems outrageous" or "that seems reasonable". Without saying what those tabs have in them, it's pretty much useless.
Firefox's memory usage has varied over the years. FF2 was terrible, and contributed heavily to the bad reputation. FF3, FF3.5 and FF3.6 were much better. FF4 is worse than FF3.6; FF5 will be better (it already is). Subsequent Firefoxes will hopefully be better again.
This is a known problem, due to some changes in FF4 regarding the discarding of decompressed images. See https://bugzilla.mozilla.org/show_bug.cgi?id=660577
Is this per-tab or global?
It's global memory usage at the moment. I'm working on https://bugzilla.mozilla.org/show_bug.cgi?id=661474 which will give JS memory usage per "compartment", which roughly means "per domain". So if a page at foo.com has a Twitter feed and some Google Analytics stuff, there'll be three compartments, one for foo.com, one for twitter.com, and one for google-analytics.com. It's not quite per-tab, but in that direction. about:memory is evolving, keep an eye on it.
No: all general purpose tools can be used harmfully. A hammer can drive in nails or stave in someone's head. But some tools are clearly designed with harmful intent in mind. There's a world of difference.
A superscalar chip has dynamic placement and dynamic issue -- the hardware is responsible for deciding which ALU each instruction goes to, and when they get issued. Doing this well requires a lot of transistors and costs power, and the hardware is rediscovering inter-instruction dependencies that the compiler could have told it.
A VLIW chip has static placement and static issue -- the compiler is responsible for deciding which ALU each instruction goes to, and exactly when it gets issued. This is really hard to do well due to variable latencies of instructions, eg. due to cache misses. It puts too much of a responsibility onto the compiler.
TRIPS is static placement, dynamic issue. So the compiler schedules the instructions onto the ALU grid. But then the hardware issues the instructions when their inputs are ready. It's intended to find a good middle ground between superscalar and VLIW in terms of what the hardware has to do, and what the compiler has to do.
Read the IEEE Computer overview paper http://www.cs.utexas.edu/users/cart/trips/publicat ions/computer04.pdf
from 2004 for a much better idea of
how it all works.
Wrong. It is entirely general purpose. Although the prototype won't boot Linux -- the prototype TRIPS boards will run under the control of an embedded Linux on a PPC machine -- that is only being done to simplify the design of the prototype chip and so no OS has to be ported to it to make the thing work.
The instruction set supports predication, ie. conditional execution of instructions. It lets you do control flow without branches.