[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [RFC] A libsvn_wc properties optimisation

From: Branko Čibej <brane_at_xbc.nu>
Date: 2004-11-09 01:43:21 CET

Gareth McCaughan wrote:

>On Saturday 06 November 2004 14:28, Philip Martin wrote:
>
>
>>Barry Scott <barry@barrys-emacs.org> writes:
>>
>>
>>>The win is that you only have to do a file open on one file rather
>>>then lots of files/directory. I'm sure that parsing one file is far
>>>faster then open 10 files. The file sizes are trivial. I have 1856
>>>bytes for 54 files in my repo for example.
>>>
>>>
>>The "I don't have any large properties, why should anyone else?"
>>argument, that came up last time as well.
>>
>>Suppose one of the files has a 1MB property, now every operation that
>>reads properties on any file now has to read that all that data.
>>
>>
>
>So, a file's entries in the props file can optionally indicate
>that the properties are stored in a separate per-file props file.
>When a file gets a 1MB property, or when it gets large numbers
>of properties, you switch to using the per-file props file. If the
>big properties go away, you switch back. With some hysteresis
>to avoid the obvious thrashing problem. ("You", of course,
>means the WC library.)
>
>That's more complicated than either "always use a single
>file" or "always use separate files", but it's still fairly simple
>and gives you decent performance in the common case
>without screwing you in the worst case.
>
>
If you think it's fairly simple, I suggest you provide a patch. Our WC
library is already a maze of twisty little passages, all alike, and this
kind of additional complication may just be over the line.

-- Brane

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Nov 9 01:43:13 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.