Closed Bug 68778 Opened 25 years ago Closed 24 years ago

large history.mab file delays displaying the first message

Categories

(SeaMonkey :: MailNews: Message Display, defect, P2)

Product:
SeaMonkey
Component:
MailNews: Message Display
Platform:
PowerPC
Mac System 9.x
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED WORKSFORME
Milestone:
mozilla0.9

People

(Reporter: tarahim, Assigned: chuang)

References

Details

(Keywords: topperf, Whiteboard: [nsbeta1+])

2001021314MTrunk and past builds in about past three weeks. It takes about 20 to 30 seconds before the first message content is displayed when a folder is opened or a new message is received. POP accounts are used in my case. This started around the time bug 66263 was filed, but it remained the same after the back-outs fiasco. Although a related bug 66528 has been resolved as WFM, it does not work for my case. I am not sure if this is the same as bug 66528, and therefore filing this as new. FYI, these are some steps I tried to see if a new profile works. 1)I tried making a new profile and copied the old Inbox.->slow. 2)I copied instead the content of Inbox to a newly created folder first, and then copied the new folder and its msf files to a newly created profile.->slow. So, it seems that creating a new profile is no help to me.
not a mail database issue. Probably not even a mail issue. I'm not seeing this myself. What theme are you using? classic? Reassigning to Scott for triage - does anyone have a dup of this?
Assignee: bienvenu → putterman
Component: Mail Database → Mail Window Front End
This happens regardless of Themes. After the initially selected message is displayed, any other message within the same folder shows up reasonably quick.
Are you opening the same message each time, and is it a particularly huge message? Does this message have HTML formatting in it at all? Does it call a webpage? If you can, save the e-mail (EML) and attach it here, and I'll try to bring it up on my mac.
Keywords: perf
QA Contact: esther → stephend
This happens regardless of the message format or size of the message. This happens with the very first message I try to view in any folder in any ofthe four POP accounts in Mail/News, and the folders contain different number of messages (from a few to nearly a hundred).
reassigning to mscott since it seems to be related to displaying a message. It doesn't sound like a collected AB problem if this also didn't work for a new profile.
Assignee: putterman → mscott
This 30 sec delay is also happening in Autocompletion of the mail address.
this is because your collected address book has gotten really big. Delete the file called history.mab in your profile directory and you should be good to go.
I agree with Scott's last comment; however, I thought we pruned the history address book when it got over the size limit.
That would affect message loading because on message load, we search for addresses, right? (If we have the pref turned on, "Enable Email address collection."
Bingo! My history.mab file got to 2.4 MB, and removing it corrected this 30 sec delay in displaying message, too. I am changing the summary to clarify the problem, then.
Summary: 20 to 30 sec before displaying the first message → large history.mab file delays displaying the first message
Stephen, yes, that's right. Hirata, there's a preference under Preferences | MailNews Preferences | Address Books where you can limit the size of the collected address book to XXX entries, e.g. 500 entries. I thought this was on by default, but I guess it's not.
It's turned on by default, but I think it's broken. I'll check.
I never touched that preference, and it is currently set at 700.
QA Contact: stephend → esther
Well, if we say that each entry takes ~4k worth of data then 700 entries would easily add up to >2.4MB. Am I correct?
yes, but each entry probably takes up more like 200 bytes. I believe what's going on here is that the address book code is not doing a compress commit to remove previously deleted entries.
Isn't bug 65086 is filed for compacting address book? I just realize it's not assigned to me.
Keywords: mozilla1.0
*** Bug 72025 has been marked as a duplicate of this bug. ***
my problem is that now with every address i enter, auto complete locks up the machine for 5 seconds. raising severity and other high visibility keywords.
Keywords: mozilla1.0, perf → mozilla0.9, nsbeta1, nsdogfood, topperf
I think I might have been too hasty marking your bug a DUP of this Pinkerton, feel free to re-open that one if you want. Candice, would they be related (code-wise) or should a dependency exist?
ok, my bug has been reopened, you can downgrade the keywords and severity here as you see fit as long as that one remains open.
Yeah, until I can find out what code dependencies we have. We know that history.mab gets opened both for reading the messages in your inbox (if you have the collection pref on) and also when you have auto complete going. What I'm not sure of is if there are optimizations to be made in different areas, or if it's just parsing the history.mab itself that is slow.
pinkerton, bienvenu has a fixed part of the on the mailnews performance branch (landing soon). from his checkin comment: "give addr db a chance to call compress commit if mork says it should". your problem is your history.mab file has gotten huge. we've got a couple bugs about not respecting the max limit. And once you go about the limit (700, I think), we never do the right thing. a temporary work around for you (to get some performance back) is to delete your history.mab file. I've had to do that to get decent compose performance.
We only read in the CAB once. So, if auto-complete locks up after you've read a message (which causes us to load the CAB), then your problem is that there are too many entries in your CAB, not that we're parsing a CAB with a lot of deleted entries - is the pref set that limits the size of your CAB? It's in prefs | mail and newsgroups |address books.
If people are experiencing this after David's checkin (which should show up in the 3/19 build), could someone try setting the collected AB to some reasonable number and see if we are obeying the preference by counting the entries. Should 700 collected ab entries add 5 seconds to autocomplete time? I would think not which is why I want to verify that we are obeying the limit. I guess it also depends on the size of the other address books as well.
Esther, I know you were looking into this. Have you had any luck making it go over the limit? marking nsbeta1+ and reassigning to chuang. I know it's a pain, but for those of you experiencing this problem, could you see if the # of entries in your collected AB is larger than the limit set in the preferences?
Assignee: mscott → chuang
Priority: -- → P2
Whiteboard: [nsbeta1+]
Target Milestone: --- → mozilla0.9
*** Bug 72025 has been marked as a duplicate of this bug. ***
I started to use a new history.mab file in 20010320 build, and it is over 1.1MB with the latest 0.8.1 build(2001032613). I do not know how to decipher the content, but I believe it has exceeded its limit of 700 entries. The delay due to this file is about 5 seconds.
I have been watching the size of history.mab file, and in recent builds, it never exceeds 400 kb. Therefore, I am marking this as WFM.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
reporter says it's working now, will verify based on that.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.