Simon Josefsson writes: > David Abrahams writes: > >>> (but it is most likely MIME decoding and displaying that >>> takes time, see below). >>> >>>>> If downloading is slower than in other clients, something is buggy, >>>> >>>> It sure seems like downloading is the problem; the attachment isn't >>>> displayed except as a MIME button. >>> >>> Ah, but the message is still copied around. Collapsing it into a >>> button is only done at the final moment of display. Yes, this is >>> inefficient. Nobody has worked on fixing this yet though... >> >> Seriously? It only takes a fraction of a second to copy 1.6M on this >> machine. > > Between buffers inside emacs? I don't know about that. >> When I look at the status line and see >> >> imap read: 774K >> >> with the numbers spinning upwards at a rate of only about 15K per >> second I grow highly doubtful that it's doing anything other than >> reading data from my IMAP server. > > Hm, yes, this sounds as if it is the downloading that takes time. Hm, > maybe it is due to subprocesses in emacs under Windows. Please try > profiling the imap and nnimap packages to see where it is spending the > time. Maybe the gnus package too, so that the total time is available > too (display probably still takes some non-negligible time). Here's the result for a `M-G' which is not retrieving any messages at all, since none were sent (but still does the slow "imap read: ..." dance up to about 24K). If you want more data, I'll send myself something big and profile that.