summary buffer takes long time to create
Ralf Fassel
Messages, 30 seconds or more, the feedback count jumps slowly in blocks
of 10), in other folders it flies (1000 Messages, less than 5 seconds,
the feedback count is barely readable because it changes so fast). Both
folders are in the same directory. Has anyone any clue what might cause
the slow summary update in some cases? MIME-encoded subjects?
Thanks
R'
Robert Marshall
I also see this and think it is something to do with threading, does
setting vm-thread-using-subject to nil (assuming you have it set to t)
before opening the folder alter the speed?
Robert
--
La grenouille songe..dans son château d'eau
Links and things http://rmstar.blogspot.com/
Ralf Fassel
| On Tue, 13 Oct 2009, Ralf Fassel wrote:
|
| > In some VM folders the VM summary buffer takes very long to create
| I also see this and think it is something to do with threading, does
| setting vm-thread-using-subject to nil (assuming you have it set to t)
| before opening the folder alter the speed?
I have it 'nil' by default:
(setq-default
;; Variable: *Non-nil value means VM should display and maintain message thread trees.
vm-summary-show-threads t
;; *Non-nil value causes VM to use the Subject header to thread messages.
vm-thread-using-subject nil
)
and just confirmed that it still is 'nil' in the folder in question.
But even with
vm-summary-show-threads nil
the generation of the summary takes a long time in this folder,
500 messages, 16 seconds. In contrast to a folder with 750 messages in
the same directory: ~2 seconds.
If it matters:
vendor_id : GenuineIntel
model name : Intel(R) Pentium(R) D CPU 2.80GHz
cpu MHz : 2792.931
cache size : 1024 KB
MemTotal: 3588128 kB
MemFree: 1163048 kB
R'
Ralf Fassel
| But even with
| vm-summary-show-threads nil
| the generation of the summary takes a long time in this folder,
| 500 messages, 16 seconds. In contrast to a folder with 750 messages in
| the same directory: ~2 seconds.
Ok, playing around with elp (emacs lisp profiler, elp-instrument-package
vm-) I found that calling the external mime decoder programs for base64
and quoted-printable are the main culprits. Obviously the lisp-based
approaches are much faster with modern processors than exec'ing the
binaries for every subject line.
Setting
;; 10/2009 on recent processors the lisp decoder is faster
;; than execing an external program
vm-mime-base64-decoder-program nil
vm-mime-base64-encoder-program nil
;; same for qp decoder/encoder
vm-mime-qp-decoder-program nil
vm-mime-qp-encoder-program nil
in my .emacs cuts down the loading time for the folder from 16 seconds
to 0.5 seconds. Unfortunately, some lisp errors creep up now when
browsing the summary, but those seem unrelated to the decoding...
R'
Robert Marshall
Yes those settings work for me too - thanks for the pointer!
Robert Marshall
I've tried these settings for a bit and I do see a problem with them
Visiting a folder is a *lot* faster but if I try to look at a message with
an attachment it is much slower (nearly instant with the default
settings c 20 sec with the nil settings - this is with a c 0.5 meg
image attachment)
Probably I'll try writing a wrapper around vm-visit-folder whcih sets
these variables to nil
Ralf Fassel
| [vm-mime-qp-decoder-program nil et al.]
| Visiting a folder is a *lot* faster but if I try to look at a message
| with an attachment it is much slower (nearly instant with the default
| settings c 20 sec with the nil settings - this is with a c 0.5 meg
| image attachment)
Yes, I see this too, but since I have only few attachments to decode, I
can live with that.
| Probably I'll try writing a wrapper around vm-visit-folder whcih sets
| these variables to nil
Please post the result...
R'
Julian Bradfield
> * Robert Marshall <sp...@chezmarshall.freeserve.co.uk>
>| Probably I'll try writing a wrapper around vm-visit-folder whcih sets
>| these variables to nil
Maybe a better alternative would be to define a new variable
vm-mime-coding-program-threshold
or something, and change vm-mime-qp-decode-region to use lisp on anything
smaller than the threshold?
Robert Marshall
> * Robert Marshall <sp...@chezmarshall.freeserve.co.uk>
>| [vm-mime-qp-decoder-program nil et al.]
>| Visiting a folder is a *lot* faster but if I try to look at a message
>| with an attachment it is much slower (nearly instant with the default
>| settings c 20 sec with the nil settings - this is with a c 0.5 meg
>| image attachment)
>
> Yes, I see this too, but since I have only few attachments to decode,
> I can live with that.
>
Though why does visiting a folder need to decode every attachment in
that folder - is it just to find the end point of the attachment?
>| Probably I'll try writing a wrapper around vm-visit-folder whcih sets
>| these variables to nil
>
> Please post the result...
>
Will do - though there's going to be a range of places where it needs to
be done - sorting using a different method, expunging...
But I suppose the visit speed up would be a start
Robert Marshall
That might be worth experimenting with, though if you were visiting a
very large folder with lots of small attachments you might still want
the lisp invoked
Robert Marshall
> On Mon, 19 Oct 2009, Ralf Fassel wrote:
>
>> * Robert Marshall <sp...@chezmarshall.freeserve.co.uk>
>>| [vm-mime-qp-decoder-program nil et al.] Visiting a folder is a
>>| *lot* faster but if I try to look at a message with an attachment it
>>| is much slower (nearly instant with the default settings c 20 sec
>>| with the nil settings - this is with a c 0.5 meg image attachment)
>>
>> Yes, I see this too, but since I have only few attachments to decode,
>> I can live with that.
>>
>
> Though why does visiting a folder need to decode every attachment in
> that folder - is it just to find the end point of the attachment?
>
>
>>| Probably I'll try writing a wrapper around vm-visit-folder whcih
>>| sets these variables to nil
>>
>> Please post the result...
>>
>
> Will do - though there's going to be a range of places where it needs
> to be done - sorting using a different method, expunging...
>
(defadvice vm-visit-folder (around vm-ad-visit-speedup)
(let ((
vm-mime-base64-decoder-program nil
vm-mime-base64-encoder-program nil
;; same for qp decoder/encoder
vm-mime-qp-decoder-program nil
vm-mime-qp-encoder-program nil))
ad-do-it))
appears to do it for me for the visits. Eventually wants putting in
vm.el into the actual vm-visit-folder definition
though as this is an interim fix I'm using advice
Kurt Hackenberg
I like that pretty well. Where the threshold applies to each
individual thing to decode: header, attachment...
Or, just tweak the code to never use an external program on headers.
Headers are small.
Ralf Fassel
| Headers are small.
Not necessarily ;-)
I sometimes get spam messages with very long 'Subject' lines which make
it impossible to forward the spam to spamcop since vm-forward-* uses the
subject line as base for a temporary file name :-/, and this fails.
(yes, they are still 'small' in the context of this thread)
R'
Ralf Fassel
| > Yes, I see this too, but since I have only few attachments to decode,
| > I can live with that.
|
| Though why does visiting a folder need to decode every attachment in
| that folder -
Huh? I only get the noticeable slowdown when I actively want to
save/view an attachment.
| is it just to find the end point of the attachment?
I guess not since the base64/qp attachments are plain easy-to-find ASCII
in the message body...
| (defadvice ...)
Good advice :-)
R'
Ralf Fassel
| (defadvice vm-visit-folder (around vm-ad-visit-speedup)
| (let ((
| vm-mime-base64-decoder-program nil
| vm-mime-base64-encoder-program nil
|
| ;; same for qp decoder/encoder
| vm-mime-qp-decoder-program nil
| vm-mime-qp-encoder-program nil))
| ad-do-it))
|
| appears to do it for me for the visits.
I adjusted that to advice 'vm-summarize' instead of 'vm-visit-folder',
since I load my Mail folders via 'find-file' and have auto-mode
everything in ~/Mail/ to vm-mode.
R'
Robert Marshall
> * Robert Marshall <sp...@chezmarshall.freeserve.co.uk>
>| > Yes, I see this too, but since I have only few attachments to
>| > decode, I can live with that.
>|
>| Though why does visiting a folder need to decode every attachment in
>| that folder -
>
> Huh? I only get the noticeable slowdown when I actively want to
> save/view an attachment.
I was referring to the situation with the default settings of the
variables which gave rise to your original post on the slowness of
creating the summary buffer
>
>| is it just to find the end point of the attachment?
>
> I guess not since the base64/qp attachments are plain easy-to-find
> ASCII in the message body...
>
Unless it's trying to cope with badly formatted attachments missing and
end marker, getting the actual size of the attached file or something?
>| (defadvice ...)
>
> Good advice :-)
>
Thank you!
Uday S Reddy
Sorry guys. I fixed this in May 2008 and uploaded it to the devo
version in July 2008.
------------------------------------------------------------
revno: 564
committer: u-reddy <u-reddy@TWEETY>
branch nick: vm-trunk
timestamp: Wed 2008-05-14 07:45:12 +0100
message:
Speeding up summary generation by using in-house mime decoding.
------------------------------------------------------------
Unfortunately, this never saw the light of day because the devo version
never got released. If you pull the VM 8.1 that I announced yesterday,
you will get the fix.
If you want to do it manually, here is the fix:
=== modified file 'lisp/vm-summary.el'
--- lisp/vm-summary.el 2008-03-13 21:00:22 +0000
+++ lisp/vm-summary.el 2008-05-14 06:45:12 +0000
@@ -430,7 +430,9 @@
(setq token (car tokens))
(cond ((stringp token)
(if vm-display-using-mime
- (insert (vm-decode-mime-encoded-words-in-string token))
+ (let ((vm-mime-qp-decoder-program nil) ; speed up decoding
+ (vm-mime-base64-decoder-program nil))
+ (insert (vm-decode-mime-encoded-words-in-string token)))
(insert token)))
((eq token 'group-begin)
(setq group-list (cons (list (point) (nth 1 tokens)
Cheers,
Uday