Closed Bug 473056 Opened 17 years ago Closed 13 years ago

Slow Browsing if Hard Drive in Heavy Use, beach ball on Mac

Categories

(Firefox :: General, defect)

x86
macOS
defect
Not set
major

Tracking

()

VERIFIED INCOMPLETE

People

(Reporter: daniel, Unassigned)

Details

(Keywords: perf, Whiteboard: [testday-20120713])

User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090108 Minefield/3.2a1pre Ubiquity/0.1.4 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090108 Minefield/3.2a1pre Ubiquity/0.1.4 Browsing with Mozilla Firefox in the unstable version I use becomes very slow if the hard drive is in heavy use, e.g. because Time Capsule is running. Scrolling and text input are in particular affected by the described slow-down. Reproducible: Always Steps to Reproduce: 1. Start browsing with Firefox, do some text input and scrolling; 2. Wait for heavy use of the hard drive (or start Time Capsule, for example); 3. Continue browsing with Firefox, do some more text input and scrolling. Actual Results: Noticable slow-down, in particular with regard to scrolling and text input. Expected Results: No slow-down (the same heavy disk-usage doesn't affect Opera and Safari). The problem is not site-specific. This Buzilla site is affected too, e.g. filling in form fields such as the one I'm currently filling in becomes a pain.
Summary: Slow Brwosing if Hard Drive in Heavy Use → Slow Browsing if Hard Drive in Heavy Use
In Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090228 Minefield/3.2a1pre Ubiquity/0.1.4, the problem is still reproducible.
Severity: normal → major
Version: unspecified → Trunk
This is still a problem for me. It has ‘bugged’ me for quite some time. Spotlight was just indexing on my machine, and UI bach-balls when you click on anything, web pages take a awful long time to open. Safari on the other hand performs fine.
Daniel, do you see this when using v3.5?
Keywords: perf
Whiteboard: [closeme 2009-10-25]
Apologies for hijacking the question pointed to Daniel. I have seen this problem since 3.0 to current 3.7a1pre.
Keywords: qawanted
Whiteboard: [closeme 2009-10-25]
Simon in comment #4 > Apologies for hijacking the question pointed to Daniel. I have seen this > problem since 3.0 to current 3.7a1pre. so even with few tabs? many bookmarks?
Summary: Slow Browsing if Hard Drive in Heavy Use → Slow Browsing if Hard Drive in Heavy Use, beach ball on Mac
One tab on a clean profile, the browsers performance is degraded some what.
This is likely to be related to the disk cache. Turning off the diskcache (browser.cache.disk.enable -> false) should help things. Bug 513008 should improve things but I've heard that minefield is still having this issue.
Simon, daniel, is you issue resolved in trunk build with Bug 513008?
Wayne, Just decided to test — just running "du -a" in terminal seems to thrash the hard drive enough. UI still feels slightly laggy, but no longer beach-balls, however some web sites cause the who UI to beach-ball for 20-30 seconds when a web site is loaded for the first time, http://arstechnica.com/ being an example. There has been a positive improvement to response while hard drives are busy in recent weeks. :)
Simon, do you still see this with Firefox 4?
Yes, UI, loading web pages etc is still very laggy when the hard drive is in use. I have tried running "du -a" again, and the app beach balls when you try to load a web page, open a menu item etc.
Whiteboard: [testday-20120713]
Yes, it is still a problem. Spotlight was reindexing the othe day and I had to use Chrome as Firefox was unusable.
Is there a way to manually trigger Spotlight re-indexing? Do you have a platter-based hard driver or an SSD?
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #14) > Is there a way to manually trigger Spotlight re-indexing? Do you have a > platter-based hard driver or an SSD? I would add, what IO is firefox doing, such that heavy external IO is having such bad impact?
Flags: needinfo?(daniel)
Not able to reproduce this on Latest Nightly (2013-01-27) and FF 19b3 on Mac OS 10.8.2 following STR from Comment 0
Thanks MarioMi It seems pretty clear now that David E. is not going to reply. so => incomplete
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Resolution: --- → INCOMPLETE
Also dropping qawanted. Daniel, feel free to reopen this bug if you can provide the necessary info so we can move forward on this bug. Thank you.
Status: RESOLVED → VERIFIED
Flags: needinfo?(daniel)
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.