move/deletes of large number of imap messages slow without caching of input and output streams during the synchronous batch copy

VERIFIED FIXED in Thunderbird 3.0rc1

Status

defect
--
major
VERIFIED FIXED
10 years ago
10 years ago

People

(Reporter: Bienvenu, Assigned: Bienvenu)

Tracking

({perf})

Trunk
Thunderbird 3.0rc1
x86
Windows NT
Bug Flags:
blocking-thunderbird3 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [no l10n impact])

Attachments

(1 attachment, 1 obsolete attachment)

(Assignee)

Description

10 years ago
If I delete to trash 100 imap messages, with a folder configured for offline use, it's quite slow. Besides the issues raised in bug 508978, it turns out that we're opening and closing both the input and output streams for each message, instead of leaving them open, which causes a massive slowdown. In the case of deleting a lot of small messages at once (e.g., deleting bugzilla messages, or archiving a bunch of messages), the speedup is quite dramatic, roughly 2-4x.
Flags: blocking-thunderbird3+
Attachment #404043 - Flags: superreview?(bugzilla)
Attachment #404043 - Flags: review?(bugzilla)
(Assignee)

Updated

10 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → Thunderbird 3.0rc1
(Assignee)

Comment 1

10 years ago
this may have broken test_imapUndo.js - I'm looking into why.
(Assignee)

Comment 2

10 years ago
this fixes the failing test case by handling the case where there's no offline store for the source folder - it's not an error, so don't treat it as such.
Attachment #404043 - Attachment is obsolete: true
Attachment #404104 - Flags: superreview?(bugzilla)
Attachment #404104 - Flags: review?(bugzilla)
Attachment #404043 - Flags: superreview?(bugzilla)
Attachment #404043 - Flags: review?(bugzilla)
(Assignee)

Updated

10 years ago
Keywords: perf
Whiteboard: [has patch for r/sr standard8]
Is this bug applicable to "Copy" too? (no store flag \Deleted, no remove from msf)
Severe slowness of copy(IMAP to IMAP) I saw in Bug 519226 Commnet #2 is this bug?
is being offline required to reproduce? 
I couldn't reproduce while online (bug 506809)
oh, and is this a regression?
(Assignee)

Comment 6

10 years ago
It's true of copy as well - all that's required is move/copying imap folders that are stored offline, in imap folders configured for offline use. No, it's not a regression. Delete immediately is not affected since there's no move/copy involved.
(In reply to comment #6)
> It's true of copy as well - all that's required is move/copying imap folders
> that are stored offline, in imap folders configured for offline use.

When I tested "copy of small 4096 mails" and saw phenomenon of Bug 519226 Commnet #2, I disabled Gloda, and I disabled auto-sync ("Message Synchronization" option is unchecked, and all IMAP folders is set offline use = off).
Is this bug relevant to "slowness of copy of may mails", even when "copy from IMAP folder to IMAP folder" case with such setting(not offline-use=On)?
(Huge virtual memory is probably relates to four "uid copy" or "uid store flage" command for each 1000 mails when copy/move of 4096 mails.)
(Assignee)

Comment 8

10 years ago
this bug is strictly about the copying of the offline copies of messages between folders. If the messages are stored for offline use in the source folder, we'll copy them to the destination folder, and that copy is much slower than it needs to be.
(In reply to comment #8)
> this bug is strictly about the copying of the offline copies of messages between folders.

I see. I'll open separate bug for Bug 519226 Commnet #2, when phenomenon of my Bug 519226 Commnet #2 is found to be irrelevant to original problem of Bug 519226, or my Bug 519226 Commnet #2 is found to be independent problem from original problem of Bug 519226.
Whiteboard: [has patch for r/sr standard8] → [no l10n impact][has patch for r/sr standard8]
Attachment #404104 - Flags: superreview?(bugzilla)
Attachment #404104 - Flags: superreview+
Attachment #404104 - Flags: review?(bugzilla)
Attachment #404104 - Flags: review+
(Assignee)

Comment 10

10 years ago
fix checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Whiteboard: [no l10n impact][has patch for r/sr standard8] → [no l10n impact]
v.fixed
Severity: normal → major
Status: RESOLVED → VERIFIED
Summary: move/deletes of large number of imap messages slow → move/deletes of large number of imap messages slow without caching of input and output streams during the synchronous batch copy
You need to log in before you can comment on or make changes to this bug.