User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-GB; rv:22.214.171.124) Gecko/20060806 SeaMonkey/1.0.4 Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-GB; rv:126.96.36.199) Gecko/20060806 SeaMonkey/1.0.4 My box is a dual-cpu 3.2GHz P4 and I'm having terrible performace problems with SeaMonkey's mail composer. I believe the problems are related to the spell checker functionality, this is because when running SM under gdb and stopping execution, the backtrace indicates Spellchecking is the cause. During the entire time of the performance problem the Browser and Mail windows stop responding and will not redraw. The performance problem lasts for over 10 seconds and maybe upto serval minutes. The performance time maybe dependant upon the number of lines in length of the mail message. Other causes of the problem are when entering email addresses To: Cc:, Bcc, into the composer. If I type in an address, then wait a second, the address turns red coloured (from black). If I now press 'return'. I experience huge delays, maybe 40 to 60 seconds each time. If I put multiple addresses on the same line with commas inbetween the delay feels like it lasts the same amount of time for each address. Why is the spell checking kicking in, when I am editing the message header and addressing details and not the message body or subject line ? I will attach some backtraces shortly and I've also got jprof to work but the results aren't what I'm expecting to see maybe they are of more help to you. Reproducible: Always Steps to Reproduce: 1. Send yourself a 500 line plain text email 2. Have at least two accounts setup, so your From: address 3. On the 500 line message click 'Forward' function 4. Now simply change the From: address, which is the top box in the mail composer
Created attachment 234467 [details] JProf output This is the JPROF output from following the Step 1 thru 4 listed above, this is the profile graph from simply changing the From: drop down from my default address to another email address.
Created attachment 234469 [details] GDB Backtrace Here is a consistant gdb backtrace after halting seamonkey during the UI freeze. The mozInlineSpellChecker:: class is consistantly the performance problem in all the other cases as well. The bad performance cases are: * When changing the From: drop down box. * When entering To:, Cc:, Bcc: addresses by pressing the Return key (as opposed to the down arrow, which does not have any performance problem and allow multiple address input without UI freezes). * When cutting and pasting large amount of text into the body of the msg
FYI The JProf attachment is truncated, I chopped 75Kb out of it to make it fit the bugzilla 300Kb limit.
Ignore my JPROF attachment, it maybe bogus on 64bit linux as jprof is broken, see bug #349166.
Could you test this in a recent branch build? Brett Wilson has made significant improvements to the spell checker with respect to performance.
What CVS tag do I checkout for SEAMONKEY ? I can only see SEAMONKEY_1_0_4_MINIBRANCH listed are those changes released to that branch ? I am currently at SEAMONKEY_1_0_4_RELEASE and have only built SM based on release versions from CVS before.
You'll want to check out client.mk from the MOZILLA_1_8_BRANCH and use it to checkout MOZ_CO_PROJECT=suite. See the build docs.  for more info. Or, you could just grab a branch build produced by tinderbox .  http://developer.mozilla.org/en/docs/Mozilla_Source_Code_Via_CVS#Checking_Out_a_New_Source_Tree  http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/latest-mozilla1.8/
Problems with the build of MOZILLA_1_8_BRANCH, the pango undefined symbol build error is a long standing problem I've seen with MOZILLA_1_8_BRANCH many months ago. Opened Bug #349393 about it.
Okay I have tested with MOZILLA_1_8_BRANCH and indeed the problem has gone away. There is no notable problem with performance. There were however 2 assertions, which I'm about to search, file and/or comment seperatly.
OK. Thank you very much for testing this on the 1.8 branch to see if it was fixed, Darryl. I'm going to dupe this to bug 324521 since it has similar steps to reproduce. *** This bug has been marked as a duplicate of 324521 ***