Live data from Hacker News

Firefox 4 RC now available

blog.mozilla.com

111–120 of 124 posts

Re: Firefox 4 RC now available

#111
post #3

Serious question here... I now use Chrome, my parents use Chrome, and almost everyone I know has converted. Most HN users seem to use it too: http://news.ycombinator.com/item?id=2105954 . Is there anything compelling in Firefox 4 to get excited about?

There's a lot to be excited about. Chrome is a respected contender, but it is far from perfect, not everyone uses it, and I'm not sure why Chrome users think it's some divine creation. It's good to have more than one awesome browser. In addition to all kinds of new HTML5 support, there's hardware acceleration, awesome SVG support, robust Audio API, and Panorama (press cmd+shift+e).

+ Firefox Sync - I can restore open desktop tabs on my android device when I am on the go

Re: Firefox 4 RC now available

#112

I'm used to Firefox 3.6 on Win7. There are a few reasons why it's my go-to browser when I'm using Windows: 1) Plug-ins like Firebug, web dev toolbar, greasemonkey, and resizeable textarea 2) Tabs are well-placed and readable, and you can simply double-click next to tabs to open a new tab 3) A proper status bar that's always visible 4) A full menu bar 5) No Adobe Flash built-in I've installed Firefox 4 RC. The colors…

> If Mozilla wanted to copy Chrome/Safari's UI, they've succeeded They haven't succeeded because they still see the need for both a search box and an address box and the tabs don't close right under where the last close button was (my biggest gripes).

The need is simple: The search box sends what you type in it to your search provider immediately. So if they're combined, there's no way to type a url without your search provider knowing what URL you typed.

Now maybe you're OK with that. But a lot of users are not (including non-technical users who don't even realize this behavior exists; once you explain what the unified bar does to them they become _very_ unhappy).

Re: Firefox 4 RC now available

#113
post #95

Since beta 10 or 11 FF4 has been really sluggish for me when opening new tabs, and at startup (aka opening lots of 'new' tabs). I don't know what changed, but it's enough to make me consider switching to Chrome. I don't want to, but RC1 is still sluggish to the point of being nearly unusable, given my browsing patterns.

Did you file a bug on this? If not, could you do that please? Since people aren't seeing this in general, your help would presumably be needed to narrow this down....

Re: Firefox 4 RC now available

#114
post #33
post #3

Serious question here... I now use Chrome, my parents use Chrome, and almost everyone I know has converted. Most HN users seem to use it too: http://news.ycombinator.com/item?id=2105954 . Is there anything compelling in Firefox 4 to get excited about?

I miss Firebug on Chrome.

Could you elaborate? In what ways do you find Chromium's Inspector inferior?

Re: Firefox 4 RC now available

#115

One thing that FF3.x has had on chrome is total memory footprint. About a month ago, when I was testing FF4, I noticed that the memory usage for FF4 and Chrome were pretty close. I personally think Chrome consumes a bit too much memory for my liking, and I was disappointed to see FF4 following suit. Has anyone noticed if the new RC is more conservative with its memory consumption?

Keep two things in mind: virtual memory usage is not the same as physical memory usage; an application consuming more memory only matters if you can notice performance degradation elsewhere in your system.

I usually only pay attention to real memory. I also notice when my real memory runs out or real memory, my machine immediately start hitting swap. I guess 4 gigs is just not enough anymore.

This is what I use to measure what I believe to be real memory usage for Chromium: https://gist.github.com/864606

Re: Firefox 4 RC now available

#116
post #17

How long after the release candidates do they usually releases the final product? Does anyone know the history of their release periods?

Mike Beltzner just said on reddit that the final should be released in a "couple of weeks". But the RC is pretty much the final. http://www.reddit.com/r/IAmA/comments/g197r/iama_were_on_the...

Re: Firefox 4 RC now available

#117

I'm used to Firefox 3.6 on Win7. There are a few reasons why it's my go-to browser when I'm using Windows: 1) Plug-ins like Firebug, web dev toolbar, greasemonkey, and resizeable textarea 2) Tabs are well-placed and readable, and you can simply double-click next to tabs to open a new tab 3) A proper status bar that's always visible 4) A full menu bar 5) No Adobe Flash built-in I've installed Firefox 4 RC. The colors…

Double-click tabbar new tab seems to have been broken, however oddly I can get it to work with middle-click.

Re: Firefox 4 RC now available

#118

Earlier quoted context omitted.

Keep two things in mind: virtual memory usage is not the same as physical memory usage; an application consuming more memory only matters if you can notice performance degradation elsewhere in your system.

I usually only pay attention to real memory. I also notice when my real memory runs out or real memory, my machine immediately start hitting swap. I guess 4 gigs is just not enough anymore. This is what I use to measure what I believe to be real memory usage for Chromium: https://gist.github.com/864606

I actually don't think that's accurate, since it naively adds up the resident set size for each Chromium thread. The problem is that there is probably a lot of shared pages among those threads - the Chromium runtime and such. I think - but I'm not sure - that the resident set size includes pages that are shared with other threads/processes.

Re: Firefox 4 RC now available

#119

Earlier quoted context omitted.

I usually only pay attention to real memory. I also notice when my real memory runs out or real memory, my machine immediately start hitting swap. I guess 4 gigs is just not enough anymore. This is what I use to measure what I believe to be real memory usage for Chromium: https://gist.github.com/864606

I actually don't think that's accurate, since it naively adds up the resident set size for each Chromium thread. The problem is that there is probably a lot of shared pages among those threads - the Chromium runtime and such. I think - but I'm not sure - that the resident set size includes pages that are shared with other threads/processes.

You may be right. I get the same memory usage numbers with my Chromium memory usage script as Chromium's "Stats for nerds", but Chromium's detailed memory usage tool does link to a bug where it over reports its own memory usage. http://code.google.com/p/chromium/issues/detail?id=25454 I guess if even Google can not figuring out how much memory Chromium is using, laymen, such as myself, are not going to do much better.

Re: Firefox 4 RC now available

#120

Earlier quoted context omitted.

I actually don't think that's accurate, since it naively adds up the resident set size for each Chromium thread. The problem is that there is probably a lot of shared pages among those threads - the Chromium runtime and such. I think - but I'm not sure - that the resident set size includes pages that are shared with other threads/processes.

You may be right. I get the same memory usage numbers with my Chromium memory usage script as Chromium's "Stats for nerds", but Chromium's detailed memory usage tool does link to a bug where it over reports its own memory usage. http://code.google.com/p/chromium/issues/detail?id=25454 I guess if even Google can not figuring out how much memory Chromium is using, laymen, such as myself, are not going to do much better…

At the very least, we can provide bounds. What you and Chromium report is an upperbound. We could provide a lowerbound defined as:

  def thread_low(t): return resident_set(t) - shared_set(t)

  lowerbound = sum(map(thread_low, all_threads)) + min(map(shared_set, all_threads))
(Forgive the Python notation, it would actually be easier to express this using actual summations if I could draw freehand, but given that I can't, I figure code would be clearer.)

For all threads in the process, we know that it must be solely responsible for its resident set minus its shared set. This already is a lower bound, but it ignores what is shared. We can increase (improve) this lowerbound a bit by figuring out what the smallest shared set among all of the threads is. If my thinking is correct, then we can be sure the total memory used won't be lower than this.

Post reply on HN