Slashdot Mirror
First Look At Firefox 3.0 Beta 2
DaMan writes "ZDNet takes Firefox 3.0 beta 2 for a spin and draws some conclusions that should be sweet music to Mozilla's ears.
"Beta 2 feels snappier and far more responsive than beta 1 (or Firefox 2.0 for that matter) and I can feel the difference on all the systems that I've tried it on — from a lowly Sempron system to my quad-core monsters. No matter what you want doing — opening a new tab, moving tabs, opening up Find, zooming in and out of the page, bookmarking — it all happens swiftly and smoothly. What surprises me about the Firefox 3.0 beta is how many memory leaks that Mozilla have fixed. Complaints of memory leaks with Firefox 2.0 were met with an attitude of "Leaks? What leaks?" Considering that there have been more than 300 leaks plugged, it's obvious that past versions leaked like sieves.""
Beta 1 did, so you'd hope Beta 2 will :)
How we know is more important than what we know.
Except for the newer bits, like most of Places and the cosmetics of new Super-autocomplete dropdown (which feels ... unrefined; functionality-wise it's doing a great job).
It's interesting to see the new animated-ish tab movement on the tab bar (when you scroll the mousewheel over it) and the animation when things like 'Remember this password?' appear. They look pretty, but are slow on some crappy video cards -- would anyone know how these 'animation' effects can be disabled?
And, kudos to the Firefox team -- I've been using v3 Beta1 for some time, and the browser does feel snappier. Of course, I haven't loaded up my 4-5 'must-have' extensions (Adblock, TabMixPlus, SwitchProxy, DownloadThemAll mainly, sometimes YSlow) so it'll be interesting to see how v3 does in "real"-use scenarios.
Go somewhere random
Apparently not, the bug against it is still open. ( https://bugzilla.mozilla.org/show_bug.cgi?id=289480 - but you'll have to copy/paste, since Bugzilla blocks Slashdot referrers.)
And before anyone jumps on this and points out that it used to, it has apparently regressed and no longer does, according to the last comments on the bug.
Not to mention that, even if it does (finally) pass Acid 2, there are still a ton of CSS3 features that Firefox fails to implement.
The response from the Firefox camp was always exactly as follows:
There may be some teensy weensy little miniscule memory leaks that could be plugged up here and there, but the reason people think there is some big memory handling problem is because of how we cache things for quick use of the 'back' button. Your browser isn't taking up hundred of megabytes of memory because of a leak, but because it makes the back button super duper fast! And since memory is so cheap these days and everyone has a ton of it, what's the big deal about half a gig dedicated to the browser anyway?
While that doesn't rule out Resource Allocation Is Initialization (RAII) - a standard C++ memory management tool - it does make it a lot more labor intensive, by requiring special code to be written for each type of object that's managed.
With templates being allowed, one can use the standard library auto_ptr, as well as reference counted smart pointer templates.
Request your free CD of my piano music.
Actual memory addresses aren't. If you allocate 1,000 pages, free a few in the middle, and try to allocate another thousand contiguous pages, you won't get them a few from here and a few from there.
I'm sure it's possible to stitch together a byte here, a byte there, and so on in your VMM, but that would be a lot of overhead and you'd need to be pretty good at packing algorithms to make that work. I'm also not sure that malloc() has to return contiguous memory.
how to invest, a novice's guide
Your misunderstanding it.
The problem with memory fragmentation is that as firefox gets used it allocates memory for buffers then stops using some of that memory. The memory unused is too small to return to the OS and if a large amount of memory is needed then more is allocated sice none of the spaces are large enough to hold whatever object that needs the memory.
It's entirely possible that firefox would have 1/3 to 1/2 of it's memory unused at any given time.
Knowing that's the problem and fixing a problem as complicated as that are two different things unfortunatly
Fragmentation affects size because without compaction, fragmented areas can't be reused for large objects: in AAAAA*****BBBB****CCCCCC, you can't use AAAAABBBB together, even if they're free, because an allocated section (*****) is in the way. So a new allocation gets pushed to at least C. You need to do compaction (most full garbage collection is also compacting, but technically the two concerns are separate, and you can compact without GC and vice-versa).
You can reduce fragmentation somewhat without compaction by using a pooled allocator, and by careful ordering of allocations, but they're stopgaps. Really, firefox needs a compacting GC, yesterday (C++ is a terrible, terrible language for doing anything in).
Over time, firefox, particularly on windows (linux has a somewhat better allocator at the system level AFAIK), ends up with a really, really fragmented memory space.
malloc need return only contiguous virtual memory. Memory mapping is not part of the C spec. However it does make sense performance and implementation wise to return a contiguous physical block if you can. In practice, memory will have to be contiguous at least to the level of the page size in use (4k is a typical example). Usually these align well enough with cache line boundaries that this kind of fragmentation is not an issue, although other posters seem to have experience to the contrary.
Firefox got replaced with some lame Iceweasel thing. Besides just looking nasty, it doesn't use the firefox settings. I lose the themes, stored passwords (Talk about lock-in! How in hell to I dig those out of firefox?), stored cookies (a bit more lock-in), plug-ins, etc.
But on older systems, the sieve like memory leaks made it inoperable within a short period of time. Hopefully this will allow those of us who run legacy hardware to have a modern relatively secure web browser.
Have you tried Opera? It's really quite good. I use it on my older Linux laptop (128MB ram) because it's the only modern browser that can show pages without thrashing the drive. I also use Opera on powerful machines - I think it's the best browser out there in terms of both the feature set and the quality of workmanship.
http://ed.markovich.googlepages.com
Sorry for replying again but I just found out that the test itself is broken and not Firefox. The reason is given here but it appears that it now renders wrong in Opera and Safari as well.
Hmm... The test breaks and IE is suddenly compliant while previously compliant browsers are not *dons his tin foil hat*
Freedom is not worth having if it does not include the freedom to make mistakes. - Mahatma Gandhi
It does pass. The original Acid 2 test page http://www.webstandards.org/files/acid2/test.html accidentally got changed a bit (so that a missing link returns error code 200 instead of 404 not found). That's why FF (and other browsers like Safari and Opera) "fail" on that page. But see the mirrored page here http://www.hixie.ch/tests/evil/acid/002/ to verify that FF 3b2 (and Safari and Opera and IE 8... OOoops! can't test that one!) do pass...
I'm running a few-days-old Minefield (SVN build) release and it passes perfectly.
If there's anyone I hate more than stupid people, it's intellectuals.
To the best of my knowledge, Firefox typically does not leak memory, at least in the conventional sense that references to memory are erroneously discarded and unused allocated memory cannot be freed. Instead, the actual heart of the issue is supposedly memory fragmentation:
http://blog.pavlov.net/2007/11/10/memory-fragmentation/
As the linked article suggests, memory fragmentation can be reduced by replacing heap allocations with stack variables, where possible, in hotspots such as the JavaScript engine. As for the heap allocations that cannot be dealt away with in this manner, effort can be made to group them together such that they are less likely to cause fragmentation.
There was a bug on the server running the test (returning a page with a 200 success code instead of 404 error). It has been fixed since.
It shows up like that because of a misconfiguration on webstandards.org. (In particular, "not found" pages are served as 200 instead of 404.) Safari and Opera will show you the same thing. Hixie is trying to get it fixed.
The version of Acid 2 on the author's website works fine.
The shareholder is always right.
The Acid2 site itself is broken. Try the Acid2 author's website.
Sorry, I call bullshit. The only time I've seen that "response" was on Ben Goodger's blog, numerous comments by ignorant fanboys, and a lot of copy/pastes by people like you. I have yet to see anyone familiar with Firefox internals make this (patently false) claim. Of course part of the problem with the Web is that most people can't tell apart a random blogger who doesn't even use Firefox, a Firefox fanboi, and a Gecko developer, even if they were to try. And they don't try.
;)
The claim I _have_ seen made is that leak bugs would be easier to fix if people actually provided some idea of how to reproduce the leak (e.g. which sites they visited in the process of leaking). At some point David Baron wrote an extension that allowed collecting such data automatically, and the results from this led directly to a number of leaks being fixed in Gecko 1.9.
The other issue Gecko 1.8 had is that it had several leak scenarios that particularly hit AJAXy apps. With the growth in the number of such apps, the leaks became more serious. Gecko 1.9 fixes those issues.
Try the beta. You might like it.
100k? You only wish!
Most web pages seem to have images, which all together add up to more than 100k. Then there's the DOM tree, the Javascript libraries, all the script state with variables, objects, etc. There's IFRAMEs and OBJECTs.
Lots more than just the surface.
Set default to not accept cookie. Then, when you're at a site where you want to accept cookies, hit F12, select Edit Site Preferences, then select accept cookies only from the site I visit
Not only that, but there are two sizes to deal with for images: compressed and uncompressed. A 100x100 pixel JPEG might take up 7K of file space, but that's 100*100*24 bits = 30K. I seem to recall reading that one of the changes they made to save memory in Firefox 3 was to drop the uncompressed copy of the image after a certain amount of time, since you can always re-extract it.
Many people don't like Opera because the UI was really cluttered back when FF 0.9 really started to become popular. Opera has made some huge improvements since then, but most people don't have the patience to go back and give it a second look.
Saying Java is nice because it works on all OS's is like saying that anal sex is nice because it works on all genders.
Now YOU are misrepresenting who end-users are. My wife, who is definitively not a geek by any standard and could hardly be described as a "power user", regularly uses the windows Task Manager to clean up / kill processes whenever her machine slows down, and I've observed a lot of other casual Windows users do the same thing. Just because you don't think end-users rely on these tools doesn't make it so.
Download Statusbar FTW.
(AKA I agree, and here's how I get around it)
Go to about:config in your address bar and set browser.sessionstore.resume_from_crash to false to stop crash recovery. Or disable session saving altogether by setting browser.sessionstore.enabled to false.
You might wan to try the Tab Mix Plus session saver, instead (you can find it at addons.mozilla.org).
Hope that helps.
This is really the worst part of modern software-development practices. When users complain about bugs, they are met with hostile demands to explain exactly, how to reproduce the bug, and the complainer is always presumed to be doing something wrong. Those, who aren't willing to put up with the hostility are not even deemed worthy of being a user -- if you had a bug, you should've reported it!
/Shrug/
Obviously, you aren't a developer. If you were, you'd know what they are dealing with.
You write some software, test it, and release it. You sink your heart and soul into it, you design it meticulously, and you are careful to leave the end-user in a position of strength - they can do whatever they want. You explain how to use it to the rest of your staff. They start training end users. Shortly, the calls start to flood back. How does NNN work? Why does "XXX" do that when you click on the button? And so on.
At first, you're all too happy to explain how NN feature works. But after a few years, while you're still explaining how feature NN works, you realize that you have documentation, notes on the website, an embedded help system, a features list, and a nice website that all explain the issue at hand.
You are willing to accomodate the fact that end users are not programmers. You ask for language, improvements, etc. that make it easier to understand what's going on.
But despite documentation and careful training, most calls I get are NOT bugs or problems, they are examples of the software doing exactly what it was supposed to do. I remember one support call I got that sounded like very serious data loss. The end-user denied seeing any error messages or anything by the program that would indicate any data loss. This end user went through several support staff before finally coming to me, the "chief tech weenie".
To avoid any ambiguity, I ran a Remote Desktop tool (VNC inside an NSIS installer) so that I could see what the end user was actually seeing. And right in the middle of the conversation, our software kicked up an error with a message that started with "PAY ATTENTION - YOU MIGHT LOSE DATA", which then explained the whole situation in pretty plain English. The end user was mid-sentence with me when this error popped up, and without skipping a beat, she clicked on the "ok" button. There was no pitch change, no pause, nothing in her voice. When I asked about the error message, she replied with "Oh, I see that all the time, and I just click OK".
So I had the fun of explaining to her that the message she hadn't bothered to read explained why she was losing data, and that the program had been laying out, to her, exactly what she needed to do so that everything worked as expected, and that she had been busy ignoring this safeguard, and that our product didn't kick up messages for the fun of it, etc...
I've even had the fun of having a user complain that they "aren't getting the latest features" of our product, only to find that when the update prompt came up, they were clicking "Cancel" without even reading the popup message.
I'm not saying that there aren't bugs that I find that are perfectly legit - but it's frustrating how many people assume that software will be sentient somehow and solve their problems for them, to the extent that they don't feel any need to pay attention to what's on the screen. They click OK, Cancel, red "X", or whatever to get the "annoying screen" out of their way so they can "get something done".
I've taken to kicking up windows that can't be dismissed unless they type some code, like: "I don't mind losing data" or "yes I want to delete this forever", or "I am liable for the information I'm about to lose". No, not that long, but you get the idea. If the end user can't dismiss the window without reading the message on it, maybe they'll read it.
Vista users are the worst - their O/S kicks up so many worthless messages they are truly desensitized to them.
Nowadays, I answer the phone politely but tersely, and I don't really bother to hide the fact that I have better things to do with my time. I go so far as to make sure that they have the right answer, then bail as quickly as I can without being openly rude.
I have no problem with your religion until you decide it's reason to deprive others of the truth.
Its not a misnomer, but its exactly the opposite problem that filesystems have. With filesystems, as files get added, and then removed or resized 'holes' are created between them. With filesystems, what happens is that the next allocation will use up all the holes and the file will be fragmented, slowing access time.
With memory its the opposite. Blocks are ALWAYS allocated in complete chunks. So the smallest holes never get filled. -Free Memory- gets fragmented instead of data, and because small bits of memory are useless the end result being that more and more space is used.
It hasn't been fixed yet, but you can take the test here: http://www.hixie.ch/tests/evil/acid/002/
Middle click on link -> open link in new tab
Middle click anywhere else -> Open/search whatever you have in your clipboard(use that a lot)
According to that test, Konqueror 3.5.8 (43/43) did a whole lot better than Firefox 2.0 (26/43). If only there were a usable KHTML variant for GTK+...
C++ has everything to do with it. Since C++ allows programmers to use actual pointers, it cannot run an automatic garbage collector and memory compactor in the background. This is because it would have to update pointers referring to data areas moved during compaction to reflect the new location, but it wouldn't know what memory elements are actually pointers, which makes this impossible.
This is why Java-style (C#-style, Python-style, whatever) references are good. They don't point to any real memory, but rather into a list of objects, where the real pointers are located. When compacting memory, only this list would have to be updated, as no data contains real pointers that would have to be updated and all pointers are available in this list.
I would use Opera, if it wasn't for the plethora of extensions available for Firefox.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
Perhaps the parent wants different tabs to be loaded via parallel threads... I am a heavy user of extensions and frequently visit some heavy sites on slow connections... A lot of times firefox just locks up while loading a particular tab (like slashdot or gmail). It would be great if I could use another tab while firefox does it's thing on the busy tab.
What does "threading between tab sessions and within tabs" mean, exactly? What operations do you want to see performed in separate threads?
Presumably (is it really not obvious to you?) the user is asking for more responsive and independent behavior both across and within tabs. Seems an entirely reasonable (and quite clear) request to me.
As for what operations to perform in separate threads, isn't that rather obvious?!! For a responsive user interface any operations that may independently hang or take time to complete should be relegated to seperate threads.
Firefox isn't just remembering some HTML code and images, that's what the cache is for, it's remembering the STATE of the web page. When you hit the back button, it (usually) remembers what you've entered in the form, where you were scrolled to on the page, etc. It remembers the page as it was when you left it so it doesn't need to render it all over again. This includes rendered CSS, Javascript states, uncompressed images, the DOM tree (as the GP mentioned). They wouldn't be able to call it "Instant Back" if it had to render the page again, because that wouldn't be very instant.
No, it really did. That's your first clue that it isn't done yet. :)
Firefox is developing more quickly because it doesn't have all of the baggage. It has its hurdles to overcome like and project, but they don't have to worry about making their browser render any page written in Netscape Composer properly. IE still has to make all those FrontPage sites look like the code wasn't shat out of some third graders science project on the effects of mold on diodes.
With good developers, lots of money, and as much savvy as anyone, Microsoft has the ability to produce all kinds of amazing software. Once they've made some great software (like a browser that renders Acid 2 properly), that's when they start adding in all of the backwards compatibility that effectively crushes the product.
I believe that Windows could be every bit as polished as OS X, as lean as Linux, and as secure as BSD if they didn't bend over backwards to maintain compatibility with every in-house-developed Visual Basic app that accesses odbc.ini, has hard coded requirements to be at the root of C:, and writes user preferences to HKLM.
Mirosoft needs to learn that sometimes things shouldn't work with their new OS. That isn't to say that Apple doesn't do this to the other extreme, breaking things with every point release and forcing developers to come out with updates to all of their software every year or two just so that it won't run in some degraded mode, but there's a happy medium in there where you do a lifecycle on the components of your OS. If they could ease people along, explain the benefits of the new way of doing something, and make a clean break instead of using hacked together tangled bundles of cruft, we'd all be in a better place.
Ok, so I strayed off topic. Anyway, I use Opera. : )
XeoMage
I wonder why this is +5 insightful: FF is famous for freezing the whole browser when one tab is blocked for whatever reason, which is a really poor design and makes it not very pleasant to use due to these freeze.
I don't know if this could be fixed without a rewrite but this shows really that FF needs more threading, and I think that it should provide better isolation using several process so when an extension crash the whole browser doesn't crash..
What does "threading between tab sessions and within tabs" mean, exactly? What operations do you want to see performed in separate threads?
"Threading between tab sessions" should be obvious - you use one thread for the abominably slow rendering job (yes, I browse Digg and Salon, why do you ask?) in one tab so that it doesn't prevent the user from interacting with the already rendered pages in other tabs. It seems like Firefox is at least trying to do some cooperative multitasking here, but that never worked very well in Windows 3.1 and it hasn't gotten any better since.
I don't know what the original poster meant by "Threading within tab sessions" (using multiple cores for rendering?), but I'd at least like to see a separate process (not just thread, but process, communicating over sanity-checked IPC) used for every plugin. You never know when Adobe's going to screw up Flash again, for instance, and it's just unnecessary for Firefox to be so closely tied internally to its plugins that a crash in one of the latter can bring down the whole web browser.
Unfortunately, making a serial code multithreaded is not just a matter of forking off a new thread or two. Separate plugin processes can probably be handled with "shim" code, but handling concurrent memory access within the browser core would at least require a total code review, albeit not a total rewrite.
I tried it with your terms, and didn't get similiar results at all.
http://www.google.com/search?q=web+page
1) 230KB: http://en.wikipedia.org/wiki/Web_page
2) 173KB: http://en.wikipedia.org/wiki/Website
3) 38KB: http://geocities.yahoo.com/
4) 317KB: http://www.steves-templates.com/
5) 189KB: http://www.howstuffworks.com/web-page.htm
6) 263KB: http://www.wpdfd.com/
7) 199KB: http://office.microsoft.com/en-us/frontpage/default.aspx
8) 112KB: http://www.webpagesthatsuck.com/
9) 267KB: http://www.benedict.com/
Measurements taken on "Net" tab of Firebug, which lists all HTTP requests for the page and the Content-Length.
This situation is exacerbated, even, by the fact that many responses are gzipped, and the Content-Length in this case represents the compressed length, rather than the space taken by the response in cache (which I assume is uncompressed, but I could be wrong here).