On Fri, Jul 1, 2011 at 02:57, Peter Samuelson <pe...@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
