Philip Martin wrote:
Stefan Fuhrmann <stefanfuhrm...@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.
