Hi Jack, and Mel,
 JS> Mel Pheasant wrote in a message to Trev Roydhouse:
 MP> on a fast ( :) ) AT I've never considered speed an issue. My
 MP> renum takes about 15-20 minutes in the wee hours of the
 MP> morning, so I've never had reason to complain. I do have to
 MP> defrag about once a year though, for it to work.
Mine takes nearer 30-40 minutes on an ol' sx16, but I guess that's fair.  I 
run many of my *.msg bases on a couple of 8Mb FileDisks, with 512-byte 
clusters, but even so I see a big speed increase after a defrag, weekly odd; 
more speedup comes from pulling areas' scattered directory clusters together, 
than actually putting an area's messages closer together, I reckon.
 JS> I've never run a database message area, however, I've
 JS> packed (renumbered?) and re-indexed databases and that
 JS> always takes a long time.  What is there about a database
 JS> message system that makes it so fast?  I know in a database
 JS> you can "mark" records as deleted so they "look" like they
 JS> are gone, but they aren't. Packing a database and
 JS> renumbering a *.msg base are equivilant tasks and should
 JS> take about the same time, particularly if the 300.msg
 JS> problem of DOS FAT is non-existant.
The big difference is not having to open, write and close a file per message.
DOS file open / close operations aren't very fast.  With a database, you open 
it the once, the rest is just seeking around, updating, maybe appending.  
From the few local Squish areas I run with Max here, I'd say it's at least 5 
times faster for operations involving bunches of messages (listing, searching 
etc.)
 JS> The ONLY gripe I have about OPUS's *.msg system is deleting
 JS> duplicate messages that aren't dupes, and Trev is fixing that.
Frankly I think that incorporating the Squish API would be the way to go for 
message databases.  It's tried and true, reliable, pretty fast, and there are 
a mob of support utilities, netmail trackers, message editors, etc, that 'do' 
Squish.  
Ian
---
---------------