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

Re: [PATCH] Saving a few cycles, part 1/2

From: Philip Martin <philip.martin_at_wandisco.com>
Date: Mon, 26 Apr 2010 10:23:20 +0100

Stefan Fuhrmann <stefanfuhrmann_at_alice-dsl.de> writes:

> further reducing my backlog of patches sitting in my
> working copy, this and the next patch optimize code
> locally - shaving off cycles here and there. The net
> effect is somewhere between 3 and 10 percent
> for repository access (ls, export, etc.).
>
> In this patch, I eliminated calls to memcpy for small
> copies as they are particularly expensive in the MS CRT.

For gcc (on Linux at least) memcpy is automatically inlined for small
copies. Obscuring the memcpy could well result in worse code.

> @@ -594,31 +636,46 @@
> semantics aren't guaranteed for overlapping memory areas,
> and target copies are allowed to overlap to generate
> repeated data. */
> - assert(op->offset < tpos);
> - for (i = op->offset, j = tpos; i < op->offset + buf_len; i++)
> - tbuf[j++] = tbuf[i];

Why are we not using memmove?

> --- subversion/libsvn_subr/svn_string.c (revision 937673)
> +++ subversion/libsvn_subr/svn_string.c (working copy)
> @@ -391,20 +391,34 @@
> apr_size_t total_len;
> void *start_address;
>
> - total_len = str->len + count; /* total size needed */
> + /* This function is frequently called by svn_stream_readline
> + adding one char at a time. Eliminate the 'evil' memcpy in
> + that case unless the buffer must be resized. */
>

If we use it a lot then optimising for a single byte might be
worthwhile. Perhaps we should write svn_stringbuf_appendbyte?

-- 
Philip
Received on 2010-04-26 11:23:58 CEST

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.