100281 - Deleting large number of addressbook cards is very slow

Status: RESOLVED WORKSFORME

(SeaMonkey :: MailNews: Address Book & Contacts, defect)

Description

[Johny]

I am on an email list from ft.com which sets unique return addresses for each
email (yes, a pain), so occasionally I go of and delete a whole wedge of
auto-collected entries. Today I had ~600 adresses auto-collected, and deleted
~400 of them. This took a long time (90 seconds, ish) and during this time my
CPU load was at 100% (AMD 1.33GHz).

The Task Manager also showed that Moz was allocating and de-allocating memory,
going from ~50Mb to ~53Mb and back a few times, so something big was getting
allocated and free'd.

This was using Moz 0.9.4 on Win2K.

J

Comment 1

[Ninoschka Baca]

Stephen, do you have any data on deleting a large number of addresses from the
Collected Address Book?

Comment 2

[[e-mail] (gone - use [e-mail] instead)]

No data yet, but I'll take a look at this.

Comment 3

[Johny]

Downloaded 0.9.5 the other day, and had to to this again as my auto-collect
addressbook was getting full. This time I paid close attention to the Task
Manager to see what happened, and Mozilla memory usage went wild! Started at
around 50MB, and then gyrated between that and 160MB of memory used, whilst
taking up 100% of my CPU time again....

That'd do nasty things to people with limited amounts of physical memory....

Comment 4

[[e-mail] (gone - use [e-mail] instead)]

Deleting 96 records in my collected address book took 10.38 seconds on a Dell P3
750 with 384MB of RAM.  I'd say that's too long.  And yes, Mozilla's whole
toolbars were unresponsive and the rest of the app basically froze until that
operation had finished.  Confirming.

Comment 5

[[e-mail] (gone - use [e-mail] instead)]

And I kid you not, Outlook Express 6 took 63/100ths of a second to delete (also 
slightly hard to measure, since it has a Confirm: dialog before you truly 
delete, in which case it may do some work in the background while that dialog 
is displayed).  I'm sure when we switch to <outliner> this will help, but I'm 
positive there is more optimization to be done than just the widget display 
code.

Comment 6

[scottputterman]

reassigning to cavin.

Comment 7

[scottputterman]

cc'ing sspitzer. This might possibly go away with the rewrite to use the
outliner.  Is this only the collected address book or do regular address books
experience the same problem.  There could be some differences because I think
the CAB behaves slightly differently. 

Comment 8

[scottputterman]

reassigning to sspitzer since I think this will be helped with the other AB
performance work.

Comment 9

[Johny]

Downloaded 0.9.7 the other day, and deleted 545 addresses (out of 660) in the
collected address book today. I didn't time it with a stopwatch, but I could see
the countdown clearly on the wee info-bar at the bottom of the window, counting
the entries one by one. 

It probably took close to one second per deleted entry, and checking the Task
Manager showed 100% CPU utilisation whilst deleting the selected CAB entries.

Comment 10

[Cavin Song]

Running the 01-10-02 commercial build, deleting 4,800 cards from a 10K card 
addressbook took about 49 seconds. So the addressbook had about 5,200 cards 
after the deletion. Then deleted another 5,070 cards and it took only 29 
seconds. So it eems like the smaller the addressbook is the faster the delete 
operation runs.

My machine is a 650 MHz Dell laptop.

Comment 11

[[e-mail] (gone - use [e-mail] instead)]

I was going to compare numbers between the 21st build (before outliner) and the
28th build (a few days after outliner landed), but the 21st build always crashes
with huge amounts of multiple cards selected.

Comment 12

[Johny]

One side note on this, the memory used by Moz stayed constant, although high
(44MB, Win2K Pro) before, during and after deleting AB entries, which is an
improvement on the 0.9.5 behaviour. 

Still think it's excessive to take 99% of CPU on an Athlon 1.33GHz for an
extended period of time to delete some 500 entries from the address book. ;)

Comment 13

[scottputterman]

+'ing for some investigation.  Perhaps we shouldn't update the card count on
every delete. 

Comment 14

[Johny]

Some number comparisons for whomever may be interested. I have also got a JPROF
log for this scenario, please advice if you wish to get a copy of it and I'll
email. The log didn't tell me anything at first glance, but then it's now
getting too late for serious thought here ;)

All of this is actually under RedHat 7.2, kernel 2.4.16, having downloaded the
source via CVS 15.Jan.2002, around 21.30 Australia time.

I also used the same address book, simply copying it back before running each
test (and, obviously, updated Moz in between tests)

350 addresses, Moz 0.9.6
  33 seconds, speeding up towards the end (card count decreasing faster) - 100% CPU

350 addresses, Moz 0.9.7
  25 seconds- 100% CPU 
  This time the entry counter at the bottom of the window doesn't change
  whilst deleting entries.

350 addresses, Moz 0.9.7+ (cvs pull as of 21.30, 15.Jan.2002, Australian Time)
  51 seconds - 100% CPU - no visual indication of progress.
  Delay likely due to this being a DEBUG build as per default build process.

Comment 15

[Robert Kieffer]

I'm seeing this as well.  I tried to delete ~300 addresses and thought Mozilla
had locked up (it took well over a minute).

The severity on this is definitely not "normal" since for all intents and
purposes, this hangs the application.  Even worse, users encountering this are
likely to kill the application ala Task Manager - which seems like a likely way
to corrupt address book files, right?

Can we re-severitize to "Critical", or at least "major"?

Comment 16

[[e-mail] (gone - use [e-mail] instead)]

major it is.

Comment 17

[Ninoschka Baca]

Trunk 2002-02-11-03: WinMe
It can appear hung because there is no progress indicator, which is similar to
Comment# 14.

This is what i tried:
I highlighted 574 addresses, pressed the Delete button and all entries remain
highlighted but there is no feedback stating the progress so this is when it
appears hung. It took about 25 seconds for the deletion process to finish. 

Comment 18

[(not reading, please use [e-mail] instead)]

my initial guesses, before I quantify and debug:

1) over notificaiton / too many delete observers
2) need to switch to batch deletes (too much UI notification / painting)
2) bad code that searches through mailing lists.

(not typically a problem for CAB, but definitely an issue for large local 
addressbooks with lots of mailing lists.)

Comment 19

[Peter Trudelle]

nsbeta1- per ADT triage, ->1.2, blocks 'miracle bug' 122274

Comment 20

[[e-mail] (gone - use [e-mail] instead)]

*** Bug 65638 has been marked as a duplicate of this bug. ***

Comment 21

[Ninoschka Baca]

Marking nsbeta1. It would be great if this could be improved.

Comment 22

[Samir Gehani]

Mail triage team: nsbeta1-

Comment 23

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 24

[Wayne Mery (:wsmwk)]

WFM current trunk
deleted 1,000 in ~15 seconds