Closed Bug 313620 Opened 20 years ago Closed 20 years ago

Opening any message causes 10-25 secs disk activity (keyword slow)

Categories

(Thunderbird :: General, defect)

Product:
Thunderbird
Component:
General
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: ken2006, Assigned: mscott)

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6 Build Identifier: thunderbird-3.6a1.en-US.win32 Thunderbird alpha/beta versions i've tried (2.6a1 & 3.6a1) cause the disk run 1-15 seconds (on my system) before the message body is displayed. Symptom appers to be one of the summary files having an inccorect or unexpected offset-pointer inot the message files, so that the entire message file must be linearly scanned in order to open any message. Reverting back to 1.0.7 is fine with same mail folders. Reproducible: Always Steps to Reproduce: 1.Open any message, new or locally copied. 2.Observe disk activity.
Reporter, there's no such thing as a version 2.6a1 or 3.6a1 ! latest 1.5 branch uses 1.5 : <http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-mozilla1.8/> latest trunk uses 1.6a1: <http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-trunk/>
Oh, sorry, I'm reporting this through my time machine. I live about 5 years in the future. (We invented a time machine extension for FF, a couple years ago) ;-) Seriously, I thought those version numbers were a bit overly ambitious! It appears my Firefox somehow altered the version numbers, due to the the auto-file rename 'feature' when a file of the same name exists. Sorry, I should have looked at the help->about version instead of filename. In fact I did try last night's build before reporting this and had the same problem, so this would apply to 1.6a1 / 20051023.
Version: unspecified → 1.5
1.6a1 and 1.07 use the same summary files, and the same checks to see if the summary file is out of date. And as I said in another bug, if we were regenerating the .msf file, you'd see a status message to that effect. Do you have Google Desktop Search installed?
I do not have any indexing engine (Google Desktop or otherwsie) installed, nor do I have any virus checking installed. And as I mentioned, the problem does not occur when I roll back to TB 1.0.7. Its only happening on the nightlies. Yes, I did see the summary file be rebuilt, once per folder, after I deleted the original to test if that was related. On subsequent opening of messages, however, there are no more summary-file-being-rebuilt messages, so presumably the summary file thinks it's working okay (and it may indeed be so). Something else seems to be amiss.
do you have any extensions installed?
Only the "Talkback 1.6a1" extension is listed by the Extenionions tool. I did have a "Dictionary Search" installed but removed that without any improvement.
A shot in the dark, but how fragmented is your hard-disk?
Hmm, I thought about that too - but it apparently defragged enough that my TB 1.0.7 can open any message in < 100ms :-) A far cry from what 1.6a is managing. Does anyone know what the command line arg(s) is to start a logged debug enabled version of TB?
I am STILL seeing this symptom after installing last nights build. Re-installing 1.0.7 always 'fixes' the problem. I can just about promise that if this doesn't get diag/fixed before the release, it will become one of the top complaints of users (murhpy's law taking advantage of what had appeared to be a corner case bug). Again, if there is anything I can do enable debug mode/logging, please tell me as I dont currently know how to debug GREs. Thx.
Still seeing this on last night's build. I wonder, if this may be related to changes in 1.5.x that fixed the 1.0.x UNIX build's old problem of not being able to correctly parse message headers from some mail servers (the problem where subject, from, date, etc appeared to be blank). What I'm wondering is if a change to the newline parser in the 1.5 branch has changed how message/block size is calculated (CRLF vs LF, etc), so that message offsets in the summary/index file are no longer valid - so a linear search is used instead on each message-open...(?). It's interesting to note that this is only happening on my windows machine - my Fedora and Mac 1.5x thunderbird builds work just fine... Is there a command line 'debug' switch that I can use to see what TB's storage engine is doing?
I should point out the following summary points so no one is at risk of dismissing this as a non-issue: -This ONLY happens on 1.5 branch builds that I've tested. -The problem does NOT happen when I re-install 1.0.x -ANY message that I open takes ~15 seconds to display, during which there is solid disk activity. -The problem occurs on any message, in any folder, for both IMAP and POP accounts. -The problem occurs even on folder with < 10 messages. -I HAVE commpacted folders - it does NOT help at all. -I have tried deleting summary files and rebuilding them; it did NOT help. -I have NO virus blocker installed, and NO background disk 'indexing' service running, an no excessive disk fragmentation. Again, they key point here is problem that this is happening -- consistently -- only on 1.5 builds. But 1.0.x builds are consistently OKAY.
This problem no longer occurs (for me) with the 1.5 release version. (thank god - and mostly the developers ;-)
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Status: RESOLVED → UNCONFIRMED
Resolution: FIXED → ---
No code identified, closing as WFM
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.