Hi everyone,
I was seeing really, really poor performance from Firefox. I'm not sure exactly when it started being a problem, but it was going on for at least a week and I certainly saw it with Firefox 12 (in F17 x86_64).
I thought I would try moving my profile out of the way to see if performance would improve, so I shut down Firefox and moved ~/.mozilla/firefox/*.default somewhere else. But then when I tried to restart Firefox, it said that it was already running but not responding. Clearly moving the *.default directory isn't the way to go.
So I then put it back where it had been and instead moved all of ~/.mozilla/firefox out of the way. After doing that, I was able to restart Firefox, and indeed performance was much better.
Having confirmed that, I deleted the newly created ~/.mozilla/firefox and moved the only one back into place so that I could try disabling extensions, etc. bit by bit to identify the culprit. But when I then restarted Firefox, the performance problems were gone!
In short, somehow moving either ~/.mozilla/firefox/*.default or ~/.mozilla/firefox out of the way temporarily and then putting it back seems to have somehow cured the performance issue. I don't understand why that might be and think it's rather odd, and I'm not sure how I'd even begin to bugzilla it. Does anybody have any thoughts? Is anyone else seeing anything like this?
jik
On Tue, 01 May 2012 09:50:22 -0400 Jonathan Kamens wrote:
Does anybody have any thoughts?
My only thought is that firefox became popular mainly because it wasn't a slow bloated mess, now it has evolved into a slow bloated mess, and chrome is becoming popular because it isn't a slow bloated mess (yet :-).
On 5/1/2012 10:14 AM, Tom Horsley wrote:
On Tue, 01 May 2012 09:50:22 -0400 Jonathan Kamens wrote:
Does anybody have any thoughts?
My only thought is that firefox became popular mainly because it wasn't a slow bloated mess, now it has evolved into a slow bloated mess, and chrome is becoming popular because it isn't a slow bloated mess (yet :-).
The major of the 'Firefox is slow' problems are caused by misbehaving themes and extensions and the the 'remnants' that some of them leave in the configuration files.
Try it with Help > Add-ons Disabled
On 5/1/2012 10:28 AM, David wrote:
The major of the 'Firefox is slow' problems are caused by misbehaving themes and extensions and the the 'remnants' that some of them leave in the configuration files.
Yes, I'm aware of that, but that doesn't explain why moving my entire ~/.mozilla/firefox directory out of the way and then moving it back without changing anything would make the performance problems go away.
We're not talking about transient issues either. It isn't at all likely that it was just a coincidence that the problems went away that particular time I restarted Firefox. As far as I could tell I was seeing them every single time I used Firefox, no matter what pages I was viewing, for well over a week, and then they instantly went away when I moved the diretories around and put them back.
As unlikely as I think it is, I have to assume that Firefox is keeping some state somewhere other than in ~/.mozilla/firefox, and moving that directory out of the way temporarily caused that other state, in whatever other location it is, to get cleaned up. That theory does seem far-fetched, but I can't think of a better one.
jik
well Jonathan Kamens you are bit lucky :) because i dont see any major changes after doing the same it's still slow
On Tue, May 1, 2012 at 8:03 PM, Jonathan Kamens jik@kamens.us wrote:
On 5/1/2012 10:28 AM, David wrote:
The major of the 'Firefox is slow' problems are caused by misbehaving themes and extensions and the the 'remnants' that some of them leave in the configuration files.
Yes, I'm aware of that, but that doesn't explain why moving my entire ~/.mozilla/firefox directory out of the way and then moving it back without changing anything would make the performance problems go away.
We're not talking about transient issues either. It isn't at all likely that it was just a coincidence that the problems went away that particular time I restarted Firefox. As far as I could tell I was seeing them every single time I used Firefox, no matter what pages I was viewing, for well over a week, and then they instantly went away when I moved the diretories around and put them back.
As unlikely as I think it is, I have to assume that Firefox is keeping some state somewhere other than in ~/.mozilla/firefox, and moving that directory out of the way temporarily caused that other state, in whatever other location it is, to get cleaned up. That theory does seem far-fetched, but I can't think of a better one.
jik
-- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
On Tue, 2012-05-01 at 10:14 -0400, Tom Horsley wrote:
On Tue, 01 May 2012 09:50:22 -0400 Jonathan Kamens wrote:
Does anybody have any thoughts?
My only thought is that firefox became popular mainly because it wasn't a slow bloated mess, now it has evolved into a slow bloated mess, and chrome is becoming popular because it isn't a slow bloated mess (yet :-).
So, nothing useful, then?
Jon, could you quantify 'poor performance' a bit? Was the entire app slow, or were certain operations - hostname resolution, for instance? - slow? Was it thrashing the disk, or the CPU? Are we talking slow _interaction_ - buttons taking a long time to respond, slow scrolling - or slow _retrieval and rendering_ of page content? Just 'poor performance' seems a bit general.
Frequent hangs for anywhere from a second to 30 seconds. Lack of responsiveness to key and button presses. Delays from when I clicked a scroll bar and dragged it to when the window actually scrolled. Frequent long delays from when an external app tried to launch a page to when the tab actually opened.
When it would finally get around to actually rendering the pages, it did that quickly, but everything involving user interaction was slow.
Jik
Sent from my iPhone
On May 2, 2012, at 6:26 PM, Adam Williamson awilliam@redhat.com wrote:
On Tue, 2012-05-01 at 10:14 -0400, Tom Horsley wrote:
On Tue, 01 May 2012 09:50:22 -0400 Jonathan Kamens wrote:
Does anybody have any thoughts?
My only thought is that firefox became popular mainly because it wasn't a slow bloated mess, now it has evolved into a slow bloated mess, and chrome is becoming popular because it isn't a slow bloated mess (yet :-).
So, nothing useful, then?
Jon, could you quantify 'poor performance' a bit? Was the entire app slow, or were certain operations - hostname resolution, for instance? - slow? Was it thrashing the disk, or the CPU? Are we talking slow _interaction_ - buttons taking a long time to respond, slow scrolling - or slow _retrieval and rendering_ of page content? Just 'poor performance' seems a bit general. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net
-- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
On 3.5.2012 00:31, Jonathan Kamens wrote:
Frequent hangs for anywhere from a second to 30 seconds. Lack of responsiveness to key and button presses. Delays from when I clicked a scroll bar and dragged it to when the window actually scrolled. Frequent long delays from when an external app tried to launch a page to when the tab actually opened.
Is there anything interesting about your setup (e.g., $HOME on NFS, NTFS, or some other kind of non-obvious configuration)?
Matěj
On 05/03/2012 03:59 AM, Matej Cepl wrote:
On 3.5.2012 00:31, Jonathan Kamens wrote:
Frequent hangs for anywhere from a second to 30 seconds. Lack of responsiveness to key and button presses. Delays from when I clicked a scroll bar and dragged it to when the window actually scrolled. Frequent long delays from when an external app tried to launch a page to when the tab actually opened.
Is there anything interesting about your setup (e.g., $HOME on NFS, NTFS, or some other kind of non-obvious configuration)?
No.
Hi
Jonathan Kamens
i am facing the same problems with firefox 12.0 in fedora 16 x86_64 it takes more then 10 seconds to open and more then 5 secs to open a new tab
well i didn't tried anything fix it yet but i will also try to do the same hope it will fix some issues
On Tue, May 1, 2012 at 7:20 PM, Jonathan Kamens jik@kamens.us wrote:
Hi everyone,
I was seeing really, really poor performance from Firefox. I'm not sure exactly when it started being a problem, but it was going on for at least a week and I certainly saw it with Firefox 12 (in F17 x86_64).
I thought I would try moving my profile out of the way to see if performance would improve, so I shut down Firefox and moved ~/.mozilla/firefox/*.default somewhere else. But then when I tried to restart Firefox, it said that it was already running but not responding. Clearly moving the *.default directory isn't the way to go.
So I then put it back where it had been and instead moved all of ~/.mozilla/firefox out of the way. After doing that, I was able to restart Firefox, and indeed performance was much better.
Having confirmed that, I deleted the newly created ~/.mozilla/firefox and moved the only one back into place so that I could try disabling extensions, etc. bit by bit to identify the culprit. But when I then restarted Firefox, the performance problems were gone!
In short, somehow moving either ~/.mozilla/firefox/*.default or ~/.mozilla/firefox out of the way temporarily and then putting it back seems to have somehow cured the performance issue. I don't understand why that might be and think it's rather odd, and I'm not sure how I'd even begin to bugzilla it. Does anybody have any thoughts? Is anyone else seeing anything like this?
jik
-- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
On Tue, May 1, 2012 at 2:50 PM, Jonathan Kamens jik@kamens.us wrote:
I thought I would try moving my profile out of the way to see if performance would improve, so I shut down Firefox and moved ~/.mozilla/firefox/*.default somewhere else. But then when I tried to restart Firefox, it said that it was already running but not responding. Clearly moving the *.default directory isn't the way to go.
You have to have the profile directory there otherwise Firefox can't check if it is open already. Try something like ~.mozilla/firefox $ for i in *.default ; do mv $i OLD.$i; mkdir $i; done And you can open Firefox with a clean profile.
Alternatively, ~.mozilla/firefox $ mv profiles.ini OLD.profiles.ini And then Firefox will think it is being opened for the first time.
Concerning the slowness being gone, maybe it was just luck?
On Tue, 1 May 2012, Pedro Francisco wrote:
On Tue, May 1, 2012 at 2:50 PM, Jonathan Kamens jik@kamens.us wrote:
I thought I would try moving my profile out of the way to see if performance would improve, so I shut down Firefox and moved ~/.mozilla/firefox/*.default somewhere else. But then when I tried to restart Firefox, it said that it was already running but not responding. Clearly moving the *.default directory isn't the way to go.
You have to have the profile directory there otherwise Firefox can't check if it is open already. Try something like ~.mozilla/firefox $ for i in *.default ; do mv $i OLD.$i; mkdir $i; done And you can open Firefox with a clean profile.
Alternatively, ~.mozilla/firefox $ mv profiles.ini OLD.profiles.ini And then Firefox will think it is being opened for the first time.
Concerning the slowness being gone, maybe it was just luck?
IMHO it was the restart that "fixed" it. I experience this "getting slow" think to happen for a long time. After several days of run, firefox needs to be restarted. 1. it's taking too much RAM, 2. usually causing higher CPU load than after restart with same tabs and history open. BTW: same I have to do with gnome-shell, so maybe some graphics card driver is leaking.
-- Pedro
Adam Pribyl
On 5/1/2012 1:53 PM, Adam Pribyl wrote:
IMHO it was the restart that "fixed" it. I experience this "getting slow" think to happen for a long time. After several days of run, firefox needs to be restarted. 1. it's taking too much RAM, 2. usually causing higher CPU load than after restart with same tabs and history open. BTW: same I have to do with gnome-shell, so maybe some graphics card driver is leaking.
Not to be too frank, but do you think I'm an idiot? Do you really think I would report serious, consistent, ongoing performance issues with an application without bothering to try restarting it first?
I restarted Firefox many times. I restarted gnome-shell. I restarted my machine. Nothing helped. Performance was poor immediately after the restart. There was no perceivable degradation over time -- it was extremely poor right from when it started up and stayed that way.
jik
Jonathan Kamens (jik@kamens.us) said:
I restarted Firefox many times. I restarted gnome-shell. I restarted my machine. Nothing helped. Performance was poor immediately after the restart. There was no perceivable degradation over time -- it was extremely poor right from when it started up and stayed that way.
In my experience, extremely slow FF performance is usually due to writing out either the assorted sqlite data files in the profile directory, or the big javascript pile that is the session storage.
Not sure why move/replace would fix that, though.
Bill
On Tue, 1 May 2012 14:11:15 -0400 Bill Nottingham wrote:
In my experience, extremely slow FF performance is usually due to writing out either the assorted sqlite data files in the profile directory, or the big javascript pile that is the session storage.
I've got one really weird slowdown I finally figured out:
https://bugzilla.mozilla.org/show_bug.cgi?id=747350
If the primary X selection happens to be held by an application running remotely in an NX session, FF takes a long time to start and interacting with the sidebar bookmarks is really slow.
What I can't figure out is why the bookmarks care about the primary X selection. I can't imagine any reason for them to want to access the selection.
On Tue, 2012-05-01 at 14:22 -0400, Tom Horsley wrote:
On Tue, 1 May 2012 14:11:15 -0400 Bill Nottingham wrote:
In my experience, extremely slow FF performance is usually due to writing out either the assorted sqlite data files in the profile directory, or the big javascript pile that is the session storage.
I've got one really weird slowdown I finally figured out:
https://bugzilla.mozilla.org/show_bug.cgi?id=747350
If the primary X selection happens to be held by an application running remotely in an NX session, FF takes a long time to start and interacting with the sidebar bookmarks is really slow.
What I can't figure out is why the bookmarks care about the primary X selection. I can't imagine any reason for them to want to access the selection.
You can mostly blame nx for that, and then partly also blame X. Assuming it is what I think it is.
Selections in X are a little unlike how you might naïvely think a clipboard works. Selections have ownership, but they do not have content until you ask for it. The PRIMARY selection is what's used when you happen to select something with the mouse (usually just text, but, depends on the application). The CLIPBOARD selection is what's used when you explicitly say Cut Copy or Paste. So if the bookmarks toolbar happens to assert PRIMARY ownership, and if the nxclient tries to keep clipboards in sync between machines, then it's going to spend a ton of time shoveling data back and forth. And because X is not an especially good bulk transport protocol, you occasionally have to use a server grab to get the content transferred intact, which locks out all other clients besides your ever-so-diligent nxclient trying to keep clipboards synced.
Lessons to learn from this:
- xulrunner maybe shouldn't assert PRIMARY ownership in this case - network transparency is not free
- ajax
On Tue, 01 May 2012 15:51:08 -0400 Adam Jackson wrote:
- xulrunner maybe shouldn't assert PRIMARY ownership in this case
That's the point for me: What on earth in the bookmarks sidebar needs or wants the selection? And it is a super long delay just in firefox.
I can run other apps that really do need to grab the selection or I can paste it somewhere, and nothing has the 20 or 30 second delay other than firefox.
I don't know what it is doing, but the available evidence is that it is something totally boneheaded (like checking the selection several times for each bookmark it draws).
On 5/1/12 6:09 PM, Tom Horsley wrote:
On Tue, 01 May 2012 15:51:08 -0400 Adam Jackson wrote:
- xulrunner maybe shouldn't assert PRIMARY ownership in this case
That's the point for me: What on earth in the bookmarks sidebar needs or wants the selection? And it is a super long delay just in firefox.
The only remotely good reason I could think of would be if the URL for the selected bookmark became the PRIMARY content. Which would be unusual, I suppose, but not unthinkable.
But a debugger would tell you for sure.
- ajax
-
Adam Jackson -
Adam Pribyl -
Adam Williamson -
Akshay Vyas -
Bill Nottingham -
David -
Jonathan Kamens -
Matej Cepl -
Pedro Francisco -
Tom Horsley