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.