Firefox - NO MORE THREADS ABOUT FIREFOX POST IN THIS JESUS CHRIST IT'S JUST A BROWSER
2,402 replies, posted
I used it a couple of months ago and what annoyed me was that it didn't have GPU support, and I have a crappy CPU, so...yeah.
And yes, it is pointless, but cool none the less.
Works with Safari 3, yay! :downs:
[b]Edit:[/b]
Yay! :v:
This is fucking awesome, nice one !
Found this on [url=www.digg.com]Digg[/url]
It's a nice big article about what the developers have done to reduce memory leaks, and reduce memory usage.
Here's What they've done:
[quote]
[b]Reduced Memory fragmentation[/b]
As I’ve written about before, long running applications such as ours can wind up wasting a lot of space due to memory fragmentation. This can occur as a result of mixing lots of various sized allocations and can leave a lot of small holes in memory that are hard to reuse.
One of the things we did to help was to minimize the number of total allocations we did, to avoid unnecessarily churning memory. We’ve managed to reduce allocations in almost all areas of our code base. The graph below shows the number of allocations we do during startup. The graph below shows we were able to get rid of over 1/3 of them! Olli Pettay, Jonas Sicking, Johnny Stenback, and Dan Witte all made a big difference here.
I carefully studied the fragmentation effects of various allocators and concluded that jemalloc gave us the smallest amount of fragmentation after running for a long period of time. I’ve worked closely with the jemalloc author, Jason Evans, to port and tune jemalloc for our platforms. It was a huge effort resulting in Jason doubling the number of lines of code in jemalloc over a 2 month period, but the results paid off. As of beta 4 we now use jemalloc on both Windows and Linux. Our automated tests on Windows Vista showed a 22% drop in memory usage when we turned jemalloc on.
[b]Fixed cycles with the Cycle collector[/b]
Some leaks are harder to fix than others. One of the most difficult ones is where two objects have references to each other, holding each other alive. This is called a cycle, and cycles are bad. In previous versions, we’ve used very complex and annoying code to manually break cycles at the right times, but getting the code right and maintaining it always proved to be difficult. For Gecko 1.9, we’ve implemented an automated cycle collector that can recognize cycles in the in-memory object graph and break them automatically. This is great for our code as we can get rid of lots of complexity. It is especially significant for extensions, which can often inadvertently introduce cycles without knowing it because they have access to all of Firefox’s internals. It isn’t reasonable to expect all those authors to write code to manually break the cycles themselves.
Basically, the cycle collector means there are whole classes of leak that we can easily avoid in both our code and in extensions, and that’s good for everyone. You can thank Graydon Hoare, Peter Van der Beken and David Baron for their amazing hard work on this.
Tuned our caches
Firefox uses various in-memory caches to keep performance up including a memory cache for images, a back/forward cache to speed up back and forward navigation, a font cache to improve text rendering speed, and others. We’ve taken a look at how much they cache and how long they cache it for. In many cases we’ve added expiration policies to our caches which give performance benefits in the most important cases, but don’t eat up memory forever.
We now expire cached documents in the back/forward cache after 30 minutes since you likely won’t be going back to them anytime soon. We have timer based font caches as well as caches of computed text metrics that are very short lived.
We also throw away our uncompressed image data as I describe below…
Adjusted how we store image data
Another big change we’ve made in Firefox 3 is improving how we keep image data around.
Images on the web come in a compressed format (GIF, JPEG, PNG, etc). When we load images we uncompress them and keep the full uncompressed image in memory. In Firefox 2 we would keep these around even if the image is just sitting around on a tab that you haven’t looked at in hours. In Firefox 3, thanks to some work by Federico Mena-Quintero (of GNOME fame), we now throw away the uncompressed data after it hasn’t been used for a short while. Not only does this affect images that are on pages in background tabs but also ones that are in the memory cache that might not be attached to a document. This results in pretty dramatic memory reduction for images that aren’t on the page you’re actively looking at. If you have a 100KB JPEG image which uncompress to several megabytes, you won’t be charged with the uncompressed size when you’re not viewing it.
Another fantastic change from Alfred Kayser changed the way we store animated GIFs so that they take up a lot less memory. We now store the animated frames as 8bit data along with a palette rather than storing them as 32 bits per pixel. This savings can be huge for large animations. One extreme example from the bug showed us drop from using 368MB down to 108MB — savings of 260MB!
Hunted down leaks
Most leaks are a pain in the ass to find and fix in any complex piece of software. There are small leaks, big leaks, and in-between leaks. If you leak a small piece of text once an hour you probably won’t notice. If you leak a large image every time you move the cursor, you’ve got a big problem. Both are important to fix, because even the little ones add up. Some leaks are only leaks until you leave a page, so they don’t show up with conventional leak-finding tools, but they make a difference if you have a page opened all day long like GMail.
[b]Leak HuntBen Turner has gotten pretty good at Leak Hunt.[/b]
We’ve fixed many leaks, ranging from small DOM objects [b]that get leaked on GMail [/b]until you leave the site to entire windows that were leaked holding on to everything inside of them when you closed them.
Overall, we’ve been able to close over 400 leak bugs so far, most of which are very uncommon, but can still occur. We’ve greatly improved our tools for detecting leaks. Carsten Book, in particular, has done an amazing job at finding and reporting leaks.[/quote]
See the rest of the article [url=http://blog.pavlov.net/2008/03/11/firefox-3-memory-usage/]Here[/url]
I'm using firefox beta 3 right now, And it works like a charm. I'd suggest that anyone who uses firefox and have a low end Laptop / PC upgrade, Since it'll free up more memory for your system.
[b][highlight](User was banned for this post (Reason: Digg (Didn't read the sticky)) [event] 42135 [/event])[/highlight][/b]
I never had a problem with memory leaks :D
I've noticed that firefox can start off using 30,000K and end up on 90,000K (as it is now) of memory quite fast, so this is a welcome update.
I think we're getting close to the actual release for Firefox 3. It just keeps getting better and better.
Looks like they have been improving on the features again but I haven't fully read through the release notes yet.
[url=http://en-us.www.mozilla.com/en-US/firefox/3.0b4/releasenotes/]Link[/url]
My firefox.exe is currently using 53,352 but just yesterday it was using 250,000k.
Good lord, they not long released the Fire Fox 3 beta 3, now another one.
Mines is using 140k right now, four tabs open.
Opera doesn't have the problem my firefox does, open up a few pages and it freezes! Too used to Firefox to switch though!
Sorry bud, you're a bit slow. There was a big thread about this the other day.
OMG FIREFOXZ!
[QUOTE=YodaEXE]Sorry bud, you're a bit slow. There was a big thread about this the other day.[/QUOTE]
Dammit, Should have Searched :tinfoil:
[QUOTE=XipLep][url]http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/firefox-4.0a1pre.en-US.win32.installer.exe[/url]
Firefox 4 alpha 1.[/QUOTE]
I use it now :v:
Thanks for Minefield Xip.
Holy crap, they just keep on finding ways to making firefox better, and I thought it was already perfect
[QUOTE=pointyface]Holy crap, they just keep on finding ways to making firefox better, and I thought it was already perfect[/QUOTE]
Hah, no web browser is perfect. I don't think any browser properly renders SVG graphics correctly.
[QUOTE=djjkps3]Hah, no web browser is perfect. I don't think any browser properly renders SVG graphics correctly.[/QUOTE]
SVG graphics?
[QUOTE=djjkps3]Hah, no web browser is perfect. I don't think any browser properly renders [B]SVG graphics[/B] correctly.[/QUOTE]
Scalable Vector Graphics graphics?
Minefield makes me e-penis feel bigger.
At the speed they're releasing them We'll have the full version before may.
There is another thread right down the page man.
EDIT: [url]http://forums.facepunchstudios.com/showthread.php?t=508614[/url]
Only thing I don't like about Firefox 3 beta 4 is PicLens isn't compatible as far as I know. :(
[QUOTE=Dantai 2]Only thing I don't like about Firefox 3 beta 4 is PicLens isn't compatible as far as I know. :([/QUOTE]
Give it time, young Padawan.
How can i turn off safesearch on google images with it, it is stopping my pornwall!
Does this work with Firefox 3 beta 4 ?
This is a very cool add on.
[QUOTE=Aksi]Does this work with Firefox 3 beta 4 ?[/QUOTE]
*facepalm*
Have you even looked at the thread? [b]NO. IT DOESN'T. BUT IF YOU WANT TO TRY IT, GET IT FROM THE OFFICIAL FIREFOX ADDONS SITE.[/b]
Awesome addon, thanks.
Sorry, you need to Log In to post a reply to this thread.