Bug 4228 - Opening inbox takes about 4 seconds
Summary: Opening inbox takes about 4 seconds
Status: CLOSED DUPLICATE of bug 4602
Alias: None
Product: Claws Mail (GTK 2)
Classification: Unclassified
Component: Folders/IMAP (show other bugs)
Version: 3.17.3
Hardware: PC Linux
: P3 normal
Assignee: users
URL:
Depends on:
Blocks:
 
Reported: 2019-07-16 21:14 UTC by J
Modified: 2022-06-05 10:48 UTC (History)
0 users

See Also:


Attachments

Description J 2019-07-16 21:14:26 UTC
I've been observing this consistently for a while now.

Opening any folder is almost instantaneous.

Opening IMAP inbox folder takes about 4 seconds.

It's not about reindexing as in http://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?id=3272. No reindexing takes place. Well I sometimes see that progress bar down there which I suppose is about reindexing and I don't know why, but it is unrelated.

I thought the inbox had too many huge messages, but I cleaned it up (63 messages, 2.5MB) and the problem persists.

When opening any folder, I get these network traces:

[21:04:43] IMAP> 7161 STATUS "Info.libvirt" (MESSAGES UIDNEXT UIDVALIDITY UNSEEN) 
[21:04:43] IMAP< * STATUS Info.libvirt (MESSAGES 17 UIDNEXT 18 UIDVALIDITY 1309849811 UNSEEN 0) 
[21:04:43] IMAP< 7161 OK Status completed (0.000 + 0.000 secs). 
[21:04:43] IMAP> 7162 SELECT "Info.libvirt" 
[21:04:43] IMAP< * OK [CLOSED] Previous mailbox closed. 
[21:04:43] IMAP< * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 
[21:04:43] IMAP< * OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)] Flags permitted. 
[21:04:43] IMAP< * 17 EXISTS 
[21:04:43] IMAP< * 0 RECENT 
[21:04:43] IMAP< * OK [UIDVALIDITY 1309849811] UIDs valid 
[21:04:43] IMAP< * OK [UIDNEXT 18] Predicted next UID 
[21:04:43] IMAP< * OK [HIGHESTMODSEQ 30] Highest 
[21:04:43] IMAP< 7162 OK [READ-WRITE] Select completed (0.000 + 0.000 secs). 
[21:04:43] IMAP- [fetching flags...]
[21:04:43] IMAP> 7163 UID FETCH 1:* (FLAGS UID) 
[21:04:43] IMAP< [FETCH data - 634 bytes]

or

[21:05:11] IMAP> 7227 STATUS Drafts (MESSAGES UIDNEXT UIDVALIDITY UNSEEN) 
[21:05:11] IMAP< * STATUS Drafts (MESSAGES 77 UIDNEXT 176382 UIDVALIDITY 1238597653 UNSEEN 0) 
[21:05:11] IMAP< 7227 OK Status completed (0.000 + 0.000 secs). 
[21:05:11] IMAP> 7228 SELECT Drafts 
[21:05:11] IMAP< * OK [CLOSED] Previous mailbox closed. 
[21:05:11] IMAP< * FLAGS (\Answered \Flagged \Deleted \Seen \Draft NonJunk) 
[21:05:11] IMAP< * OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft NonJunk \*)] Flags permitted. 
[21:05:11] IMAP< * 77 EXISTS 
[21:05:11] IMAP< * 0 RECENT 
[21:05:11] IMAP< * OK [UIDVALIDITY 1238597653] UIDs valid 
[21:05:11] IMAP< * OK [UIDNEXT 176382] Predicted next UID 
[21:05:11] IMAP< * OK [HIGHESTMODSEQ 78595] Highest 
[21:05:11] IMAP< 7228 OK [READ-WRITE] Select completed (0.000 + 0.000 secs). 
[21:05:11] IMAP- [fetching flags...]
[21:05:11] IMAP> 7229 UID FETCH 1:* (FLAGS UID) 
[21:05:11] IMAP< [FETCH data - 1024 bytes]
[21:05:11] IMAP< [FETCH data - 1024 bytes]
[21:05:11] IMAP< [FETCH data - 1024 bytes]
[21:05:11] IMAP< [FETCH data - 320 bytes]

Here's what I get when opening Inbox

[21:06:28] IMAP> 7336 STATUS INBOX (MESSAGES UIDNEXT UIDVALIDITY UNSEEN) 
[21:06:28] IMAP< * STATUS INBOX (MESSAGES 63 UIDNEXT 55910 UIDVALIDITY 1238412229 UNSEEN 0) 
[21:06:28] IMAP< 7336 OK Status completed (0.000 + 0.000 secs). 
[21:06:28] IMAP> 7337 SELECT INBOX 
[21:06:28] IMAP< * OK [CLOSED] Previous mailbox closed. 
[21:06:28] IMAP< * FLAGS (\Answered \Flagged \Deleted \Seen \Draft $Forwarded $MDNSent NonJunk Junk) 
[21:06:28] IMAP< * OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft $Forwarded $MDNSent NonJunk Junk \*)] Flags permitted. 
[21:06:28] IMAP< * 63 EXISTS 
[21:06:28] IMAP< * 0 RECENT 
[21:06:28] IMAP< * OK [UIDVALIDITY 1238412229] UIDs valid 
[21:06:28] IMAP< * OK [UIDNEXT 55910] Predicted next UID 
[21:06:28] IMAP< * OK [HIGHESTMODSEQ 46616] Highest 
[21:06:28] IMAP< 7337 OK [READ-WRITE] Select completed (0.000 + 0.000 secs). 
[21:06:28] IMAP- [fetching flags...]
[21:06:28] IMAP> 7338 UID FETCH 1:* (FLAGS UID) 
[21:06:28] IMAP< [FETCH data - 1024 bytes]
[21:06:28] IMAP< [FETCH data - 1024 bytes]
[21:06:28] IMAP< UID 55834 FLAGS (\Seen)) 
[21:06:28] IMAP< [FETCH data - 673 bytes]

or

[21:11:23] IMAP> 7689 STATUS INBOX (MESSAGES UIDNEXT UIDVALIDITY UNSEEN) 
[21:11:23] IMAP< * STATUS INBOX (MESSAGES 63 UIDNEXT 55910 UIDVALIDITY 1238412229 UNSEEN 0) 
[21:11:23] IMAP< 7689 OK Status completed (0.000 + 0.000 secs). 
[21:11:23] IMAP> 7690 SELECT INBOX 
[21:11:23] IMAP< * OK [CLOSED] Previous mailbox closed. 
[21:11:23] IMAP< * FLAGS (\Answered \Flagged \Deleted \Seen \Draft $Forwarded $MDNSent NonJunk Junk) 
[21:11:23] IMAP< * OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft $Forwarded $MDNSent NonJunk Junk \*)] Flags permitted. 
[21:11:23] IMAP< * 63 EXISTS 
[21:11:23] IMAP< * 0 RECENT 
[21:11:23] IMAP< * OK [UIDVALIDITY 1238412229] UIDs valid 
[21:11:23] IMAP< * OK [UIDNEXT 55910] Predicted next UID 
[21:11:23] IMAP< * OK [HIGHESTMODSEQ 46616] Highest 
[21:11:23] IMAP< 7690 OK [READ-WRITE] Select completed (0.000 + 0.000 secs). 
[21:11:23] IMAP- [fetching flags...]
[21:11:23] IMAP> 7691 UID FETCH 1:* (FLAGS UID) 
[21:11:23] IMAP< [FETCH data - 1024 bytes]
[21:11:23] IMAP< [FETCH data - 1024 bytes]
[21:11:23] IMAP< [FETCH data - 699 bytes]

I don't see any relevant difference.

From a few tests, the pause can happen either after the last line above ([21:06:28] IMAP< [FETCH data - 673 bytes]) appears in the network traces window, or after the first "1024 line" at the end of the trace ([21:11:23] IMAP< [FETCH data - 1024 bytes]) but even then, the lines afterwards get the same timestamp so it looks like it is the display that is being delayed, not the network request/response.

Is there any specific processing on Inbox that could justify the symptoms ?

Thanks.
Comment 1 Paul 2019-07-27 14:31:52 UTC
(In reply to comment #0)

> Is there any specific processing on Inbox that could justify the symptoms ?

Filtering and/or Processing rules.
Comment 2 J 2019-07-29 22:55:37 UTC
> Filtering and/or Processing rules.

I use none of these. I should have mentioned that.

(Filtering is done server-side with Sieve.)

BTW, the only modules I use are

- AttRemover (probably unrelated)
- RSSyl (probably unrelated)
- Notification (unrelated as well, I guess)
Comment 3 Paul 2022-06-05 10:48:30 UTC

*** This bug has been marked as a duplicate of bug 4602 ***

Note You need to log in before you can comment on or make changes to this bug.