On Fri, Jul 1, 2011 at 02:57, Peter Samuelson <peter_at_p12n.org> wrote:
>
> [Hyrum K Wright]
>> I like this idea, but it would seem to introduce an additional stat()
>> call* for every attempt to fetch a revprop, because you'd first have
>> to check the "old" location, and then the packed one.
>
In simple approach: yes, we have to. But we already have
db/min_unpacked_revprop and we can update it when user modifies the
revprop.
This depends how often we expect revprop to be changed? I assume that
revprops are changed infrequently.
But I think that for server extra stat() is not so important as for
client and working copy library. Anyway when we access SQLite database
it checks for .db-journal and .db-wal files.
> Technically not an extra stat(), but an extra open(). Not the same.
> Especially since the "common case", as you put it, is that the open()
> returns ENOENT, file not found. _That_ case may or may not be
> expensive, but it's quite different from the usual consideration of
> whether stat() is expensive. Not least because stat() is usually
> considered in context where a file _does_ exist and various information
> about the file gets looked up to populate the stat structure.
>
Btw on Windows dry open() takes a lot more time than stat(). I don't why.
--
Ivan Zhakov
Received on 2011-07-01 15:38:29 CEST