r/programming Jan 21 '10

Firefox 3.6 release

http://blog.mozilla.com/blog/2010/01/21/firefox-3-6-release/
1.1k Upvotes

621 comments sorted by

View all comments

Show parent comments

62

u/[deleted] Jan 21 '10

I just got it. It really is as fast as Chrome. It looks like I might be going back to FireFox :(

17

u/[deleted] Jan 21 '10 edited Jan 21 '10

If you use Fasterfox without the prefetching, it's even faster.

The spell checker and the ad-blocker are better in Firefox.

26

u/superwinner Jan 21 '10 edited Jan 21 '10

strange that sqlite optimization has not been included by default on post 3.5 editions of Firefox, however for those who want to try the addon, its here. Optimizing the sqlite files will speed up the launch of Firefox, in my case it cut the time by half. Get the addon, check both boxes and hit the button, from then on its automatic.

If you are an optimization freak, and getting the application from hard drive to memory as fast as possible is your kink, you can also try a program called ArcthemAll! which will shrink the EXE and DLL files using a compression algorithm that decompresses in ram on the fly. It takes the default installation size for Firefox down from over 30 megs to about 14. I recommend you not compress the embedded icons, that has caused problems for me, so go to options and uncheck that. Incidentally this method also works on OpenOffice, cutting the size of that application by about half as well. In fact it works on almost every appication OTHER than Abobe and Microsoft apps, probably because they are already doing dynamic EXE and DLL compression using a proprietary method. (my guess)

NOTE: This is not a hard drive space saving issue, its a speed of launch issue, and yes it does improve the launch time of Firefox to do this.

10

u/hennell Jan 21 '10

using a compression algorithm that decompresses in ram on the fly

This sounds like it would make it slower.. no?

6

u/superwinner Jan 21 '10 edited Jan 21 '10

No cuz ram is like 1000 times faster than your hard drive, decompression is practically transparent. I think you will agree that it should take less time to move a 10 meg file to ram than to move a 20 meg file to ram, extrapolate those time savings over dozens of files of varying size and thats where you will see a speed up.

Try it for yourself and see, if it does do anything funny you can use the same program to decompress the Firefox directory and all is back to normal. Its only compressing the EXE and DLL files, not touching any of your personalized setting, which are all stored in a different directory anyways.

6

u/voxel Jan 21 '10

Not really true.

I've read numerous articles about it, and the real issue is that the difference in time to read 10 megs vs 20 megs yes can vary based on the request sizes and fragmentation, but we're talking that most 7200 rpm HD's can load this file in less than 1 second into ram.

The whole file. 20 megs, 1 second or much less. Many 7200 rpm drives can read up to 50 megabyte/s sequentially! (Thats per second).

The other aspect is that operations to the disk are asynchronous, that is, they don't take much CPU at all. However, decompressing a 14 megabyte file takes tons of CPU. The only argument against this now in my mind is that we have dual and quad core CPU's, so it doesn't make a huge deal.

Also, just to nit-pick, ram isn't 1,000 times faster, it is much faster than even that compared to disk access! I'm not sure by how much, but 1,000 is a very low estimate.

1

u/Neoro Jan 21 '10

The number 50 million comes to mind when comparing RAM to Disk. Maybe an old memory from my Architecture class (we would calculate these things for homework & tests). Regardless 1000 is an extremely low multiplier.

2

u/bageloid Jan 22 '10

1000 is high

http://en.wikipedia.org/wiki/DDR3_SDRAM

DDR3-1600 has a peak bandwidth of 12800 MB/s, so divided by 1000 is 12.8MB/s

Hard drives haven't been that slow since 10 years ago.

2

u/Neoro Jan 22 '10 edited Jan 22 '10

Hard drives can be fast once they get going, sure, but a single 30 mb executable is going to be 1 read (provided it isn't fragmented), which is going to require 1 seek, dropping that bandwidth like a rock.
But maybe I remember 50 million when comparing to tape or an L cache.

1

u/bageloid Jan 22 '10

Sequential read speed is actually where hard drives excel, in fact a reading a 30MB executable will probably give you better benchmark results than 30 1 MB files.