🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: gnu.emacs.vm.bug
Article #9342

summary generation

#9342
From: kyle
Date: Fri, 18 Oct 1991 22:41
44 lines
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-vm
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

Show 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