Closed Bug 431764 Opened 18 years ago Closed 18 years ago

Closing firefox becomes slow over time

Categories

(Firefox :: General, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: nulldomain, Unassigned)

Details

(Keywords: perf, qawanted, regression)

Attachments

(2 files)

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008043015 Firefox/3.0pre Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008043015 Firefox/3.0pre I have been running trunk builds since last year, and lately firefox has started to become extremely slow in closing down. To the point where it takes around 3-4 seconds after you've hit the 'X' or File->Quit before it actually closes down. I've found that if you remove your profile folder and start fresh, firefox closes instantly again. However over time it slowly takes longer and longer to close. I'm not seeing this behavior with firefox 3b5 on my winxp partition, so it might be Linux only. Reproducible: Always
Keywords: qawanted, regression
Which file in your Firefox profile is most responsible for the slowness? Can you use a profiler such as gprof to figure out the call stack(s) where Firefox is spending too much time?
Keywords: perf
Version: unspecified → Trunk
Can you point to me to some docs or give me some steps on how to setup firefox to run gprof?
Attached file profile1 —
Ok, here is the first profile I got. This is my first time running a profiler so I'm not sure if I did it right. I set JPROF_FLAGS="JP_START JP_FIRST=3 JP_PERIOD=0.010", started firefox then closed it.
Attached file profile2 —
I ran the profiler again, this time with JPROF_FLAGS="JP_START JP_FIRST=3 JP_PERIOD=0.010 JP_REALTIME".
I meant to add that this seems to be completely related to history. If I go to Tools->Clear Private Data and only clear history, performance returns to normal.
Joseph, could you please attach the .prof files? Thanks! Daniel.
It ´seems´ (after short review) that when you close FF, SQLite is waiting for some write synchs. I may take this one, but before, Joseph, could you please confirm you don´t see the same in Windows? What I see in windows is: after you close FF, the window closes, but the process remains (visible in Task Manager) for a while, so I'm wondering if you experience the same thing, just that the window waits for the process to finish (whereas in Windows, the GUI goes away immediately). If my hypothesis is true, then: - the problem is common to Win and Linux, just that the GUI goes away in Win, but not in Linux (about the latter: I can see that there are some X functions awaiting for the synch as well). - what would the solution? a) Maybe we could mimic the Win behavior in Linux, by doing the synch in some hook after the GUI goes away (so you don't see the GUI while synch occurs) b) We could avoid waiting for the synch (in both cases), and close everything leaving the operating system to take care of synchs. I'm not sure about this one, and I'm not even sure this would be possible (since all this seems to be related with SQLite). So, in summary: please try to reproduce the same in Windows (I will try in Linux), with the Task Manager at sight, and tell me if you see the same. Additionally, I'll start looking to the code, so maybe I can make a prototype solution of the 1st alternative. Daniel.
I'm thinking https://bugzilla.mozilla.org/show_bug.cgi?id=421482 might have something to do with this?
Ok, so I think this bug was my fault. I was building with --enable-system-sqlite and I was using sqlite version 3.5.8 which had a performance bug. I upgraded sqlite to 3.5.9 and I no longer am seeing this bug. Sorry for the spam.
Status: UNCONFIRMED → RESOLVED
Closed: 18 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: