On 4/7/06, Peter N. Lundblad <peter@famlundblad.se> wrote:
> Since the new format reduced the CPU time by about 35%, I think the
> performance gain is a combination of I/O and CPU, especially when much
> of the entries files is ion the OS cache, which is the case when you
> perform multiple operations in a row. But I don't think this should
> be very hard to try, so I'll give it a shot to get some perspective.
There might be some opportunities to make our XML parsing a bit faster still.
A few things looking at read_entries:
1) APR_BUFFERED isn't turned on, so any small reads or writes will
cause extra libc/syscall activity. Combined with...
2) No need to call read_full in the do loop. However many bytes it
reads at a time is fine by us. read_full would cause multiple I/O ops
of a non-optimal chunk size - the better strategy is to just process
what we got from one libc/syscall invocation instead of forcing the
return to be CHUNK_SIZE (16k).
It *might* be worth it to see if doing a mmap of the entries file
would help - that would make the parsing faster as we can avoid a
buffer copy entirely. Solaris, FreeBSD, and a few other OSes have a
madvise option (MADV_SEQUENTIAL) that works with mmap that tells it as
we read the memory location we can discard the previously read bytes
and we will fetching the next bytes. This isn't insignficiant in some
other usage patterns like this.
Your recent changes to handle_start_tag to use a scratch pool helps
save memory, but we could/should avoid the strdups that come with
svn_xml_make_att_hash. It might just be worth teaching
svn_wc__atts_to_entry how to handle the atts array directly to avoid
the scratch pool altogether.
The joys of staring at XML parsing code in ra_serf for the last few
days... Hah. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 7 10:08:18 2006