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

Re: Patch: reducing code duplication by using functions

From: Oto BREZINA <otik_at_e-posta.sk>
Date: Wed, 02 Sep 2009 21:05:00 +0200

Dear Dmitry,

Fact is that I cant find that manual whitch tells why using index
instead of changing pointer is faster.
> I've done a test - a locally allocated (automatic variable) buffer of size 2048 is processed 100 million times in a loop. First time it is referenced as buffer[i], second time there're two pointers - head set to the first element and tail set to the last, tail is decremented along the pass.
> Code is compiled with VC++7, Full Optimization (/Ox), GetTickCount() is used to measure time.

I did similar test (Borland C++ Builder/CodeGear BDS2009), with similar
result. Only notable difference: for 10char strings second version was
faster obout 14%, on 1000char strings first was faster about 16% and in
all other cases 100,10k,100k char strings there were same. I have no
clue what this means.
Other point here is that both codes while optimized for size give almost
same code - *inc/dec* /of pointer/ instead of *mov* /reg,
[base+offset]/, which was declared as faster.
I also used */for/* for first variant and while for second. /*For*/ may
be slower.

I thought about to try asm, but priority is under 0 :)
> The first variant takes 157375 ms, the second one - 157406 ms. They are almost equal - about 0,01% difference.
> The emitted machine code is very similar - the key difference is that with buffer[i] the comparison is done by comparing a register to a constant and in the head!=tail the value to compare against (head) is first loaded from memory (the compiler fails to store it on a register). However in the latter case head is unchanged and therefore each such load results in a cache hit.
> Decrementing or incrementing the buffer index or pointer used for buffer access (traversing direction) should also not result in any significant difference. The cache has no idea of what code runs in the processor core - it only works with actual memory accesses. If several subsequent accesses occur at adjacent addresses and all of them correspond to one cache line they all result in cache hits. Regardless of traversing direction once the cache miss occurs the line is fetched and several subsequent accesses result in hits.
> I guess TSVN has some code that needs performance tuning. But the string processing routine we discuss here is not the number one candidate.
100% agree I just note that code while you redesign it. And start thing
about it.
> Best wishes.
> Dmitry.
Thanks for your time. I did know that this it far from main TSVN issues.
It just took my attention and I tried to share my opinions.



To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-09-02 21:06:57 CEST

This is an archived mail posted to the TortoiseSVN Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.