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)
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).
Reporter | ||
Comment 1•8 years ago
|
||
Whoops, forgot to mention--system environment Windows 7 Pro 64 bit with 16 GB RAM and plenty of swap and disk space.
Comment 2•8 years ago
|
||
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?]
Updated•8 years ago
|
Severity: normal → major
Reporter | ||
Comment 3•8 years ago
|
||
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...
Comment 4•8 years ago
|
||
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.
Description
•