My startup time massively regressed between Firefox 3.6.8 and 4.0 beta 1 — it's still a problem with 4.0 beta 2. Some delayed startup event is freezing the browser for about 30 seconds. It seems to happen on a timer after tabs open and windows are raised, or is triggered if I focus the location bar. I'm guessing it's in Places for that reason, and because it started misbehaving when I imported all my tagged delicious bookmarks so I could switch to using Firefox sync instead. DB files are large but not huge: Places.sqlite = 40 MB, formhistory.sqlite 1.5 MB. I can supply my places data (securely) if necessary. If this is not a known bug, I can do a bisection search if someone points me in the right direction.
Could you get a shark profile of the hang?
Also, I tried vacuuming the database (using the Vacuum Places Improved extension back in 3.6.8) and it didn't make any noticeable difference.
Here's the Shark Time Profile (all functions > 1.0%). 34.1% 34.1% libmozsqlite3.dylib sqlite3_get_table 19.8% 19.8% libmozsqlite3.dylib sqlite3_value_bytes 4.3% 4.3% libmozsqlite3.dylib sqlite3_randomness 4.3% 4.3% libmozsqlite3.dylib sqlite3_db_config 3.9% 3.9% libmozsqlite3.dylib sqlite3_compileoption_used 3.4% 3.4% libSystem.B.dylib __spin_lock 3.1% 3.1% libmozsqlite3.dylib sqlite3_enable_shared_cache 3.0% 3.0% libmozsqlite3.dylib sqlite3_os_end 2.7% 2.7% libSystem.B.dylib pthread_mutex_lock 1.9% 1.9% libSystem.B.dylib pthread_mutex_unlock 1.9% 1.9% libmozsqlite3.dylib sqlite3_malloc 1.9% 1.9% libmozsqlite3.dylib sqlite3_value_numeric_type 1.4% 1.4% libmozsqlite3.dylib sqlite3_result_null 1.4% 1.4% libmozsqlite3.dylib sqlite3_free 1.1% 1.1% libmozsqlite3.dylib sqlite3_create_function16 1.0% 1.0% libmozsqlite3.dylib sqlite3_sql
Hmm, that's not so useful (need to see more of the stack). Can you attach the whole thing as a text file please?
Hrm, that is not the tree view I was expecting. Can you make sure you expand all items (there is a menu option). Trying to see more of the stack here to try to identify what is going on.
Sorry, first time using Shark. Here's the tree view with "Show All Branches" checked in Advanced Settings. If this isn't what you're looking for, I'll post the entire 4.5 MB profile and you can do try working with that.
Attachment #460904 - Attachment mime type: application/octet-stream → text/plain
Looks like it is spending a bunch of time in sqlite3_randomness and reading from the disk, which is...weird?
Don't know. Does it matter that all that is inside nsPrintSession::Release, or is that just where the delayed startup event triggers? System is running normally otherwise. Disk space is low but sufficient and it doesn't run out during Firefox startup. I made a new copy of the profile to see if fragmentation was a problem, but it doesn't seem to make any difference.
(In reply to comment #9) > Don't know. Does it matter that all that is inside nsPrintSession::Release, or > is that just where the delayed startup event triggers? I think that is unreleated.
Does the same happen if you take your places.sqlite and copy it into a new and clean profile? if so, would be nice to have a copy of your database (compressed by mail would be fine)
Yes, it does. Marco, I'll send you a copy of places.sqlite.
I've tried your db and for sure I can't reproduce on Windows, it is pretty fast instead. Will have to check if it's Mac only.
I should have mentioned that it does happen in Safe Mode so, in case there was any doubt, it's not an add-on (not that there are many 4.0 compatible add-ons yet).
Could this be the same lock-contention issue in bug 563538?
(In reply to comment #15) > Could this be the same lock-contention issue in bug 563538? I think so at this point. Still weird that this appears to be mac only :/
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 563538
You need to log in before you can comment on or make changes to this bug.