Article View: gnu.emacs.vm.bug
Article #9342summary generation
From: kyle
Date: Fri, 18 Oct 1991 22:41
Date: Fri, 18 Oct 1991 22:41
44 lines
2835 bytes
2835 bytes
Jamie Zawinski writes: > In message <9110112041.AA05591@info7.infosys.dpw.com.infosys> Steve Baumgarten wrote: > > I bet there are a lot of messages in that folder that don't have the > > magic X-VM-v5-Data header. > > You're right, that was the problem. Building a digest didn't do it for > me, but after doing > > (let ((rest vm-message-list)) > (while rest > (vm-stuff-attributes (car rest)) > (setq rest (cdr rest)))) > > computing the summary buffer only took about twelve seconds. But parsing the > message-lists still took the same amount of time as before. (It's still slow > enough that I'm going to continue using find-file.) > > All the messages that were in that folder got there by this path: arriving > in my inbox; having a summary generated for them; and then being copied with > vm-save-message. I had assumed that this sequence of events would cause a > fully computed X-VM-v5-Data header to be saved, but the one that was saved > was mostly empty (none of the date/time fields filled in, for example.) The X-VM-v5-Data header is filled in as the information is requested. If a VM command requires that the Date header be parsed then it is parsed and the information is cached. If the message is modified (an attribute change occurs) then when the folder or the message is saved the X-VM-v5-Data header is written with all cached information. > I think that before outputting a message to a file, the X-VM-v5-Data header > should be fully computed, so that a little extra time is spent at save-time > instead of potentially a lot of time later. > > Actually, I'd be perfectly happy having the magic header fully computed as > soon as a message arrives in my inbox. Hmmm, I've been thinking of doing even _less_ at VM startup instead of more. Deferring generation of the invisible part of the summary and deferring folder parsing are a couple of examples. I am doubtful that generating a full X-VM-v5-Data would speed things up, since the things that you reference tend to get cached anyway.
Technical Details
Message-ID:
<9110182241.AA11606@wendy-fate.UU.NET>Path:
arc1-ca.pugleaf.net!gmdzi!unido!mcsun!uunet!wendy-fate.uu.net!bug-vmReferences:
<9110101824.AA00240@prsun1.pr.oracle.com> <9110101842.AA25417@wendy-fate.UU.NET> <9110111754.AA03244@rodan.UU.NET> <9110111837.AA18995@thalidomide> <9110112041.AA05591@info7.infosys.dpw.com.infosys> <9110120020.AA19549@thalidomide> <BAUMGART.91Oct11Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f6829,d5569dca0eb20a35 X-Google-Attributes: gidf6829,public X-Google-ArrivalTime: 1991-10-19 08:33:40 PST Path: arc1-ca.pugleaf.net!gmdzi!unido!mcsun!uunet!wendy-fate.uu.net!bug-vm From: kyle@wendy-fate.uu.net Newsgroups: gnu.emacs.vm.bug Subject: summary generation Message-ID: <9110182241.AA11606@wendy-fate.UU.NET> Date: 18 Oct 91 22:41:53 GMT References: <9110101824.AA00240@prsun1.pr.oracle.com> <9110101842.AA25417@wendy-fate.UU.NET> <9110111754.AA03244@rodan.UU.NET> <9110111837.AA18995@thalidomide> <9110112041.AA05591@info7.infosys.dpw.com.infosys> <9110120020.AA19549@thalidomide> <BAUMGART.91Oct11 Sender: bug-vm-request@uunet.uu.net Lines: 44