On 4/6/06, Julian Foad <julianfoad@btopenworld.com> wrote:
> Well, I have no particular objection to changing the format if it turns out to
> be a good idea after due consideration, but let me put the other side of the
> argument. Don't be too hasty. A 19% reduction in wall-clock time is worth
> considering, but not amazing.
I don't know, I think it's a pretty nice speed bump for big trees...
> Is this format that you are playing with one that you made up? Introducing Yet
> Another File Format is a bad thing in general, however simple it seems to be.
> There is significant but unquantifiable value in using a standard format. If a
> new format were to replace one of the other formats that we currently use, it
> would be more reasonable, but this won't be replacing XML.
>
> If, as you say, the savings might be mostly due to the reduced file size, then
> try compressing the files on the fly (reading/writing theough a zlib stream).
> Does that give a similar saving in wall-clock time? Presumably the CPU time
> would be increased, but is that important?
ZLib is probably worth trying, although I'd be somewhat against a
compressed format due to readability issues...
I wonder how much of the gain we could get just by making the xml less
verbose. I've seen big speed gains in previous projects by taking
verbose xml and making the tag/attribute names smaller (i.e. on the
order of a single character each), it's less readable than the current
xml format, but not as incomprehensible to the naked eye as the pipe
separated one, and if it's really just size that's giving the speed
gain it's worth looking at.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 7 02:32:04 2006