Closed Bug 1279383 Opened 8 years ago Closed 8 years ago

handling of large address lists in compose is incredibly slow/CPU intensive

Categories

(Thunderbird :: Message Compose Window, defect)

45 Branch
defect
Not set
major

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 1294078

People

(Reporter: davofanmail, Unassigned)

Details

(Keywords: perf, Whiteboard: [dupme?])

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0
Build ID: 20160502172042

Steps to reproduce:

compose a new mail with no contents or subject
use T'bird address book to select 1000 names/email addresses
drag/drop the address list to the email "to" field
(this is in preparation for doing a mail merge)


Actual results:

With version 45, this operation now takes over 10 minutes with 100% CPU utilization.  In prior versions, it took at most a minute or so.
Note that all the list members do indeed end up in the mail address list as they should.


Expected results:

This should have completed in a minute or so (obviously, even shorter would be nice...but I'm just pointing out a performance regression vs prior versions).
Whoops, forgot to mention--system environment
Windows 7 Pro 64 bit with 16 GB RAM and plenty of swap and disk space.
David, thanks for filing this.  Do you have ldap lookup enabled?

I see two factors
1. number of addresses already specified in compose window
2. number of addresses being added

tested on fast machine with nightly build (and once in safe mode), address book size ~750. (total addresses of all address books >1,500)  I tested small and large amounts, and start seeing a delay when
- number of address already in compose was in the range of 100-200. 
- number of addresses selected/being added is 50 or more
The effects are much worse for factor #2 - which feels like it is not linear to the number of addresses involved.  There may be some element of bug 705837 involved but I think there is more. Because I tested adding 700+ addresses and the perf hit is dramatic - multiple "unresponsive script" dialogs. When I disabled ldap lookup, the perf hit seem to not be as bad.  

Consider bug list https://mzl.la/1PONnVz   Questions: 
- if we are copying addresses directly from an address book rather than typing - can't address autocomplete be bypassed?
- Is the performance linear to the number of addresses involved?

And, I never considered this thought before David's report here - this must be horrible for a user with a large mailing list, eg mailmerge list, where numbers of addresses are in the thousands
Status: UNCONFIRMED → NEW
Component: Untriaged → Message Compose Window
Ever confirmed: true
Flags: needinfo?(davofanmail)
Keywords: perf
Summary: handling of large address lists incredibly slow/CPU intensive → handling of large address lists in compose is incredibly slow/CPU intensive
Whiteboard: [dupme?]
Severity: normal → major
Hi Wayne, 
Thanks for looking into this so quickly.
No, I don't have ldap lookup enabled.
re two factors:
1.  the symptom happens when there are no addresses already in the composite window.  this is a drag and drop to an empty window
2.  number of addresses added--this practice has worked OK for most previous releases.  this is a new behavior on an existing use-case.

Note:  with lists of only a few hundred, symptom does not occur...the window swallows the list in a few seconds.

No question this is a non-linear phenomenon.  And yes, I'm one of those people doing the mail-merge thing.  Total address book is about 8000 addresses, the individual mails are typically 1000-1500 each.  Used to work fine, but not any more...
This is being handled in bug 1294078
Status: NEW → RESOLVED
Closed: 8 years ago
Flags: needinfo?(davofanmail)
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.