[Zope] Announce - Audio Product

[marc lindahl]

> From: Toby Dickenson <tdickenson@geminidataloggers.com>

> Firstly Zope does seek over the pickle data, reading only the FileStorage
> transaction metadata. However it will be faster if those pickles are small,
> since more than one transaction metadata block will fit in one disk block.

I think this depends entirely on how the pickle data is stored, and of
course, the filesystem.  For the latter, I highly doubt there is much
difference lookiing for a new file and seeking inside an ready open data.fs.
Perhaps Shane Hathaway (who seems to have done some work on the
FileStorage...) can provide an answer to how data.fs is walked.

> Further, it is more likely that the disk blocks will be available faster due
> to read-ahead in your OS.

Read ahead, caching at many levels (on the disk drive, controller, OS
driver, virtual memory system), it will definitely obfuscate the issue to
the point where only empirical testing can give the answer.

> 
> Secondly the internally-stored files will consume *more* ZODB objects - one
> object for each 64k of file size. This is necessary for the memory-reduction
> tricks mentioned earlier in the thread.

That's true, and depending on how the data.fs is walked it could have an
impact.  But they are very low level objects, and I would imagine that if
the data.fs is searched heirarchically, instead of linearly scanned (which
makes no sense), then they wouldn't have much impact, since they're linked
only to one other object, and have almost no relationship (inheritance) to
anything, except persistence.  Also, percentage-wise, since there's only one
extra per 64K, it's a very small overhead of extra objects.