Peter N. Lundblad wrote:
> "Just For Fun", I experimented with replacing our current XML-based
> .svn/entries syntax with a line-based, |-separated syntax. It
> actually turns out that there is some overhead associated with using
> XML, but it is not extreme overhead.
[...]
> The result is that this row of operation requires 19% less wallclock
> time and 35% less CPU time. [...]
>
> ON another note, the size of all the entries files in the GCC tree
> decreased from 8.2 to 4.2 megabytes, which probably explains much of
> the time savings.
[...]
> So, I propose to replace our current XML entries files with some
> variant of this new format.
[...]
> Opinions?
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.
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?
Basically, I think this is something to be considered but not something to be
rushed in for v1.4 or that, on the present evidence, warrants a new file
format. By all means post a patch and let it be tried and profiled a bit more
by other people, and also work out the escaping details and post the formal
description of the format, and we'll take it from there. Documenting a design
is usually a very good way of showing up its strengths and weaknesses.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 7 01:53:45 2006