Slashdot Mirror
Firefox 3 Performance Gets a Boost
jason writes "Mozilla has been working hard at making Firefox 3 faster than its predecessor, and it looks like they might be succeeding. They've recently added some significant JavaScript performance improvements that beat out all of the competition, including Opera 9.5 Beta. And it comes out to be about ten times faster than Internet Explorer 7! Things are really starting to fall into place for Firefox 3 Beta 4 which should be available in the next week or two."
Hopefully it can best Safari's Javascript performance. Firefox is pitifully slow compared to WebCore's javascript core.
One of the ways I usually demonstrate to people the advantage of Firefox 2 over IE7 is to show them the difference in time it takes to open multiple tabs. With Firefox, they open as fast as I can hit CTRL-T, but with IE it takes about a second for each one.
I stole this sig from a more creative user.
To be honest, I hate it. WTF have they done with my handy URL bar? It used to be a place where I could type "slas" and get the slashdot URL come up. Even worse for "news", as it "handily suggests" all the pages in my history that have "slas" or "news" in my history.
Heads up for all those trying Firefox 3 is Oldbar. I suggest you get it if you don't like the new 'innovations' by Mozilla Corp.
The Safari team recently introduced some native javascript functions, which showed very impressive speed. It looks like the next release Safari will be up there as well (if not even faster still).
I'm off to download the latest Firefox to see how the two compare (on both Windows and OS X platforms).
The Mothership
Firefox 3 is going to include support for the new Java SE 6 runtime environment.
This is a new implementation of the Java Plug-In that features increased reliability, ability to specify large heap sizes, ability to select a specific JRE version to execute a particular applet, and support for signed applets on Windows Vista.
The New Plug-in is designed to work with: - Internet Explorer 6 and 7 on Windows XP and Windows Vista - Firefox 3 on Windows XP, Windows Vista, Solaris and Linux
Personally, I've been wanting to use the Firefox 3 beta for some time, primarily because of the performance and speed boosts over Firefox 2, but my favourite add-ons still aren't compatible.Note: The new Plug-in does not work with Firefox 2, and no support is planned for this browser with the New Plug-in.
http://gemal.dk/blog/2008/02/24/firefox_3_gets_a_new_java_plugin/?from=rss-category/Back up your Firefox Profile and start clean.
in this thread
The Mothership
Silly question perhaps, but is optimized to use SSE, SSE2, SSE3, or any other instruction sets?
Life is not for the lazy.
Flash has more and more accessibility support, but PDF is the Page Description Format. It's meant for print output and says nothing about the meaning of the contents of the document, just how they are supposed to look on the screen and on the page.
The good thing about tag-based formats like HTML is that--provided someone's following the standard--they can be fairly easily parsed regardless of the output format. With XHTML, you can read stuff on your screen, the blind can use screen readers, and web developers can easily extract and transform elements from a given document things are good as they are.
Finally, why do you think PDF = lean and mean? Acrobat proves that a PDF reader can get hideously bloated.
Safari 3.1 is supposed to be really fast as well. How do they stack up?
note that this is a javascript test, not a html test, but the main problem is, you need to break the problem down into many components, including, but not limited to:
a) efficient networking
b) lexical analysis
d) parsing.
e) DOM tree construction (required because it's available to javascript)
f) javascript lexical analysis
g) javascript grammar parsing
h) javascript compilation to bytecode
j) javascript execution by vm (including subtasks: initialization, execution, security checks, etc)
k) rendering output
It's probably even more complex than above, but it's a long process to go from <html><body><p>hi!</p></body></html> to a page that has "hi!" on it. Longer if it needs to execute javascript safely as well.
It wasn't so much a memory leak issue as it was memory fragmentation.
The benchmark used in this article is a JavaScript benchmark, but PGO was enabled for most components of Firefox, not just the JavaScript engine. And even if only the JavaScript engine improved in speed, you'd see a speed boost despite having JavaScript disabled in web pages, since parts of Firefox itself are implemented in JavaScript.
The shareholder is always right.
Microsoft's biggest mistake was thinking people wouldn't write complicated apps in Javascript. They supported it, in their usual half broken style, but it created the only widely deployed cross-platform system for running code that Microsoft has ever implemented. Now, with Firefox 3 running so fast javascript might become THE platform. It's hilarious because Javascript started out as such a kludgy platform and now it is becoming a serious contender if only because it's the only cross-platform thing Microsoft ever supported.
Speed is great, speed is fine. I like speed. But how doing something about the fact that Firefox was that 550 megabytes of memory with only about 10 windows / tabs open? And I don't want to hear any nonsense about caching. Sorry, but I have NOT downloaded 550 megabytes of data today, and even if I had, I don't want it ALL cached.
This has to be the #1 complaint about Firefox -- that it's such a memory pig. Is the design so brain damaged that it just can't be fixed? Or do the developers just not care?
Yeah, my computer has a lot of memory, but I'd like to devote that to VMWare, Photoshop, video editing, etc. Not a browser!
Sometimes it's best to just let stupid people be stupid.
No, recently the developers have found that few leaks are left, so that to reduce memory usage further they had to change their focus to reducing fragmentation. Originally, the problem was leaks, it's just that once the worst ones were fixed fragmentation became responsible for a larger fraction of the memory usage. This a continuation of people trying to find one single cause of high memory use. As I and others have been saying for years, there is no one cause. There is no "the memory leak" or "the memory issue", just as there is no "the crash problem" or "the security problem".
What a fool believes, he sees, no wise man has the power to reason away.
I could have sworn that PDF was Portable Document Format. All your other points about it are correct though.
This sig is intentionally blank
Well someone had to, so I ran the numbers for OS X. All of the below were on OS X 10.5.2 running on a MacBook:
I guess if you're a Safari or Firefox person you can look forward to some really fast Javascript performance either way.
JSON, code decompression, and traversing XML are things that a browser does with JavaScript, some more often than others. Even in those cases, I wouldn't be surprised if browsers had parsers that 'helped' the common browser JavaScript tasks with faster native-library interfaces instead of purely native JavaScript interpretation.
Why is the parent comment marked as troll? It was reported a few weeks ago that the next version of Safari, 3.1, would see major JavaScript performance gains due to the latest WebKit builds. This article uses the beta Windows 3.0 version to compare to.
"Sufferin' succotash."
OS X proves that a PDF reader can be as fast as HTML. Faster in some cases -- no need to lay out and render large tables, complex CSS, etc.
Do you even lift?
These aren't the 'roids you're looking for.
I disagree that it looks bad on os x (using it right now), but it has already been addressed. If you have ff3b3, you can download the os x theme.
I have. Still ass. doesn't go lighter when it's backgrounded, stays the same dark grey as if it were foregrounded.
Open-Source seems good for getting a job 90% finished and completely ignoring the 10% polish required to make it an app of the same quality as closed-source
and does a single tcp socket's stalling not cause the whole damn thing to seize up?
What the internet desperately needs is an application transfer protocol completely distinct from HTML.
We already have a perfectly good one. It's called HTTP. While the acronym may be misleading, it has nothing to do with HTML. In fact, no protocols (that I know of) have anything implicit to do with HTML.
I agree that we should be getting the damn code out of your hypertext, but that doesn't necessitate a new protocol.
Just to give you the alternate perspective- I love the idea of Opera, and use the kick-ass mini (and mobile) versions every day. But on my desktop, it just seems so foreign. It's like a swiss army knife, with inbuilt functionality poking out every which way, and (in my head) obstructing the work I've got planned- It doesn't feel like it's mine.
I realise that it mostly is amazing, and I'm not satisfied with Firefox by any means, but Opera just feels alien; a bit like when you start messing about with WINE after a long period of not needing to.
I realise that seems woolly as fuck, but I guess Opera is sufficiently advanced that such intangible and abstract criticisms become the only valid ones.
"Be light, stinging, insolent and melancholy"
Or does a single tab still cause the entire browser to freeze up?
___
If you think big enough, you'll never have to do it.
Luckily many pages don't need Javascript or at least not a lot of JS to render.
What I find more important are the lockups I get because of limitations to multi-threading in FF, at least under Linux. There are situations where one window locking up means all windows lock up. There are situations where some initial connection to a host being stuck means all of the browser locks up. One can only guess, because FF does not indicate what the problem is -- but more frequently than is funny, I have FF get unresponsive, not re-painting windows anymore and just eating up CPU and memory without reacting until I kill it.
This sucks and this doesn't seem to have changed in FF 3.
I always see these benchmarks and wonder "why does this matter?". The only time I ever see Javascript run too slow or tax my CPU is when it's buggy and then it'll probably throw up all sorts of warnings anyway. This is on any browser I've used and any system.
What matters to me is the imperfect implementation of Flash (it's not really their responsibility but it is their problem) which often eats up 100% CPU from random flash objects or causes firefox to freeze. Another annoyance is Firefox being frankly poor at displaying large HTML files (when you go on websites with insanely large lists for instance). Where as IE and Opera display these as the page is downloaded. Firefox, for me, freezes, much like notepad will when you open a 2meg+ file . Sometimes it'll recover and display the page after a minute or so, sometimes I have to ctrl+alt+delete.
I had these problems with Firefox 2 exactly running the default Ubuntu version. I downloaded the firefox 3 beta 3 from the website and it is so much better it is unbelievable.
- Where as before FF2 would use around 500 meg it now only uses around 50 meg
- Flash no longer crashes the browser
- Javascript no longer crashes the browser
- Those long pauses as it is doing something that stalls the browsers operation are gone.
I couldn't believe the difference.
I've seen similar complaints, but have never been able to reproduce any such problem. I can open and close tabs all day, and Firefox does not suck up all my memory, or even a significant portion of it. I can't even run it long enough to come close to sucking up all of my memory (it would take several weeks of use every day without ever closing it). Could you explain how the rest of us could see the problem? If you do, we could report it and the problem could be fixed.
What a fool believes, he sees, no wise man has the power to reason away.
There is no "the memory leak" or "the memory issue", just as there is no "the crash problem" or "the security problem"
Once upon a time there was this OS named Windows Millennium Edition, also known as "the" in your examples above.
You haven't even mentioned the number one problem that makes Firefox slow when it's been open for too long: memory allocation costs associated with heap fragmentation.
You must be using windows, on Linux it doesn't do this, you just download the zip file, extract and run.
Um, PDFs can be made just as accessible as HTML documents, and Adobe's PDF tools have good integrated support for assistive technologies built in.
PDF accessibility is a lot like HTML accessibility; you have to know what you're doing to make it happen, but you can make it happen.
Read my blog.
That's the 10% that takes hard work.
"Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
I've got to agree with you. Memory usage, per se, isn't going to affect speed, *if* that memory isn't constantly being addressed.
If the memory in question are rendered page caches, which aren't going to get touched unless they're viewed. As long as the allocation tables are efficiently indexed, i don't see how memory usage is directly related to speed.
Firefox is actually using FreeBSD's new malloc (jemalloc; PDF) internally, instead of the default OS allocater on all platforms. It's quite fast and has less fragmentation than other implementations.
I've also known other people to complain about it - while others have no idea what they're talking about. You have to love sporadic issues.
I'm pretty sure it has to be a combination of minor flaws in Firefox (as not every program I run has this issue), Windows XP (with memory handling far better than previous versions, but still not exactly the gold standard of memory management), and all the myriad changes to my system's configuration over time.
It does it on both my work computer and my home computer. Then again, they're both XP Pro machines. They're very different in terms of hardware, which tentatively rules out a specific hardware config. The memory on my home machine is double that of my work machine, but the highpoint seems to be about the same - so I doubt it has much to do with total system memory. What sites I hit seems to have no relevance. The only other common factor I can think of is that I run NoScript on both - though if I remember right the problem predated my use of that (I first noticed it a while back, and had actually hoped 2 would fix it).
The main issue seems to be that a specific amount of memory is eaten up when you open a site in a tab - but closing that tab often doesn't clear up the space. I just now closed every tab except Slashdot - and it went from 157mb (when I had 14 tabs open) to a minuscule 153mb. From experience, waiting for it to dump cache is ineffective. If I close the program, the memory clears itself just fine - but only if there is no other Firefox window open. I'm guessing that multiple Firefox app windows share a footprint.
Then again, saying "all" of my memory was an exaggeration. I've rarely seen it hold on to much more than 150mb after closing all but one window, though if I go on for very long without at least shutting down firefox, that minimum can creep up - and on a few occasions really has taken more memory than I actually have on my machine (virtual cache trash time). It's also probably not a noticeable problem unless you're a heavy multitasker (in which case that footprint becomes painfully obvious).
I've noticed it doesn't happen on my fiance's Vista machine, or on any 2003 Server boxes I've run it on. It may be a problem that only occurs on XP, or it just doesn't like the way I smell.
However, if you are able to reproduce it, you'll see it happen whenever more than one tab has been opened. Opening one tab, then clearing it, seems to work - but once a second tab opens, clearing the original tab clears it's footprint, but any tab opened after that exhibits the problem.
Do not confuse "Freedom of Choice" with "Free Will".
I think instead of multi-threaded, the developers should seriously consider a multi-process model. The front end skin could broker back end processes and provide a display buffer. This would provide free page isolation. If a plug-in goes haywire, bizerk or whatever the kids says these days, the front end can just kill off the process and continue humming along.
-rd
I have found JavaScript performance depends immensely on what it was written for.
For instance Gmail in FireFox is really fast, almost as if it weren't a web application.
However, Gmail in Opera is a lot slower.
Possibly due to how FireFox caches and similar, but either way, theend result is that Google Apps is a lot faster on FireFox.
This is my footer. There are many like it, but this one is mine.
I beg to differ -- Webkit is actually pretty damned good, in terms of speed, stability, and compliance. About the only thing it lacks is universal support from webpages, but then, that used to be a problem for Firefox -- there's not a whole lot a browser can (or should!) do about sites that don't follow the standards.
I'm going to say IE. Whatever replaces HTML must work in IE, and it must do so without any fuss.
But that's only because I'm assuming we'd replace HTML with something like XHTML, which is (inexplicably) broken in IE.
PDF is no more or less "fully graphical" than HTML. In fact, if I remember right, PDF is based on PostScript, which is a Turing-complete language designed to format documents for printing -- sounds pretty textual to me.
Flash might be, but do you really want the Internet to be based around keyframe animations?
The difference is, HTML is designed for the Web.
PDF is designed for print. I'd much rather have a website which I can resize to any window I want, and let the text flow to fit, than a PDF document which has pages that are certain proportions, exactly, leaving huge margins and gaps between pages for no reason. PDFs certainly have their place, but the Web ain't it.
And I only say that because I don't know enough about the other capabilities of PDF to know if it can quite replace the Web as we have it -- plugins, javascript, video, etc.
Now consider Flash. Adobe certainly seems to want this to happen. AIR embeds a SQLite engine, a Webkit engine, and probably some other things as well, basically allowing you to develop a desktop app in HTML and Flash -- but since it's Webkit everywhere, you don't have to worry about browser compatibility. And Flash itself keeps getting more and more capabilities, though it still sucks for video, and still isn't hardware-accelerated at all in the browser window.
But it's really frightening that you want to replace HTML, an open standard that works just about everywhere, with Flash, a wholly proprietary system that is only relevant to this discussion because Adobe has seen fit to port it to enough platforms. I'm still waiting for my 64-bit Linux Flash, and I can't do a damned thing about it, other than contribute to reverse-engineering projects like Gnash.
And yes, I know you can get the SWF spec. You can get it under a license which forbids you from developing a player. Woo hoo.
Stop right there.
You want us to stop working on improving HTML engines, and start working on adding features that don't currently exist to PDF or Flash? And then write a browser around them?
Think about that for a minute. Do you really expect it to be easier that way?
HTML is easy to parse. It's even easy to render. It's broken HTML that's hard.
And XHTML would be even easier -- but again, there's that Internet Explorer problem. That, and most websites aren't ready, either.
Now, if your suggestion was to start over completely, I'd be all for it. There are many things I wish had been done differently. But that would take an order of magnitude more time and effort than your crazy-assed PDF and SWF ideas.
Don't thank God, thank a doctor!
Except that Mozilla relies on HTML, CSS, XUL and JavaScript for it's whole user interface, for it's extension system, ...
So, even with NoScript which stops the webside JS, there is still tons of JS to execute...