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.
Status: NEW → ASSIGNED
Target Milestone: --- → Thunderbird 3.0rc1
this may have broken test_imapUndo.js - I'm looking into why.
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.
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?
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.)
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]
fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Whiteboard: [no l10n impact][has patch for r/sr standard8] → [no l10n impact]
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.