Re: [PATCH] Saving a few cycles, part 1/2
Philip Martin wrote:
> 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.
Variable-sized memcpy is hard to inline. The MS
compiler, at any rate, won't use intrinsics here.
But a "static inline fast_memcpy" function would
probably be the best solution here.
>> @@ -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?
In LZW-style (de-)compression, overlapping copies
are used used to generate repeating patterns. This is
exactly what memmove would prevent (I tried this
just out of curiosity and it failed).
>> --- 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?
It is used frequently but maybe only called from one
other function. I will write a separate function if I find
another place adding single chars.
Received on 2010-04-27 01:19:41 CEST
This is an archived mail posted to the Subversion Dev