delete bad cache files on separate thread to reduce startup time

VERIFIED DUPLICATE of bug 103851

Status

()

Core
Networking: Cache
VERIFIED DUPLICATE of bug 103851
16 years ago
15 years ago

People

(Reporter: Brent Gustafson, Assigned: gordon)

Tracking

({perf})

Trunk
mozilla0.9.9
PowerPC
Mac System 9.x
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

16 years ago
I've been noticing that after any time Mozilla crashes on my computer, the next
time I restart, the browser takes a good 10 minutes to load before I even get a
browser window (this is not an exageration).  During this time I hear heavy disk
activity, and the Mac watch icon is shown, and I can't switch to any other app.
 Trashing the Mozilla directory in the Documents directory on my Mac "solves"
the problem, but then I lose all of my preferences, etc.

Perhaps this is "normal" activity, but I can't see how it is.  What's it doing?
 Is this an issue, or intended?  It'd be nice if I didn't have to redo my prefs
every few days.

My hardware:
Mac G3 (B&W) 350mhz
492mb RAM (VM off)
MacOS 9.2.2
Build 200212503
Mozilla clears the cache directory after a crash
(the cache is in an unkown state)

Is mozilla faster if you choose a smaller Cache size in the preferences ?
I dunno how fast a mac is but 10 minutes seems to be very long...


Updated

16 years ago
Keywords: perf
(Reporter)

Comment 2

16 years ago
That would explain it I believe.  I had my cache set to over 50MB and when I
went to trash my Mozilla folder it had over 8,000 files in it, which took
forever to delete from my system.  I'm assuming that was what the wait was for,
and the heavy disk activity.  I've set my cache to zero for the time being,
if/when the browser crashes again I can find out if that was the culprit, but
I'm pretty much guessing that's what it was.

One question...why does mozilla clear the cache on a crash?  If there's some
underlying reason for it that I don't know about then that's cool, but for
someone who has a lot in their cache, it's rather annoying to have to sit and
wait while it deletes thousands of tiny files off your HD.
The cache is cleared so we don't read half-written data from entries that got
corrupted by the crash later...
-> Networking:Cache
Assignee: asa → gordon
Component: Browser-General → Networking: Cache
QA Contact: doronr → tever
and marking wontfix (The cache _must_ deleted after a crash)
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME
(Assignee)

Comment 6

16 years ago
There may be a couple things I can do to lessen the impact on startup time. 
I'll try and get to them for 0.9.9.

One is to use the cache block files for data streams, which is covered by bug 81724.

It might also be possible to move the old cache directory aside and delete the
files on a separate thread, while continuing startup.  I'll leave this bug open
to cover that proposed fix.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Summary: Startup takes over 10 minutes after any browser crash. → delete bad cache files on separate thread to reduce startup time
Target Milestone: --- → mozilla0.9.9

Comment 7

16 years ago
gordon, would you mark this bug confirmed if you want to keep it around?
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 8

16 years ago
*** Bug 144092 has been marked as a duplicate of this bug. ***

Comment 9

16 years ago
Is this only Mac?

Comment 10

16 years ago
Eh, no. But since HFS is so slow when deleting thousands of files, it's much
more visible on that platform.
*** Bug 160185 has been marked as a duplicate of this bug. ***
*** Bug 161465 has been marked as a duplicate of this bug. ***

Comment 13

15 years ago
can we make this a dupe of bug 103851 ?
(Assignee)

Comment 14

15 years ago
Yup.  I don't know why I didn't dup it before.

*** This bug has been marked as a duplicate of 103851 ***
Status: NEW → RESOLVED
Last Resolved: 16 years ago15 years ago
Resolution: --- → DUPLICATE

Comment 15

15 years ago
verified duplicate
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.