tags:

views:

137

answers:

3

I have called snprintf a few times consecutively with different arguments. I take the time needed for each snprintf. I found that the first call to snprintf takes the longest time. After that, the time needed to call the same function decreases until it converges. What is the reason for that? I have tried with other functions and also exhibit the same behavior.

I am asking this because it relates to testing the code performance. Normally in the main program it would be only be called periodically. However, when I test the function separately like in a loop, it would be faster, hence, resulting in inaccuracy of the measurement of performance.

The first call takes 4000++ ns, second call takes 1700ns, third call takes 800 ns until around 10++ calls, it is reduced to 130ns.

snprintf(buffer, 32, "%d", randomGeneratedNumber1);
snprintf(buffer, 32, "%d", randomGeneratedNumber2);
   .
   .
   .
+3  A: 

The most likely explanation is that both the function code will end up in the instruction cache after the second time around just like the input data (if there is any) will be in the data cache. Furthermore, some branches may be predicted correctly the second time around.

So, all in all, "things have been cached".

EboMike
This is one reason that a lot of benchmark procedures require that the benchmark be loaded and run for a time *before* it can be assumed that its results mean anything. In addition to the cache, you might be waiting for the page containing `snprintf()` to be paged in to the processes working set, for instance.
RBerteig
+2  A: 

Your program may be dynamically linked to the library containing snprintf(). The first time delay would then be what is needed to load the library.

mouviciel
or page in its text to the working set.
RBerteig
@mouviciel: the library would be already loaded. What would be left to do would be to resolve the `snprintf` symbol and fixup its address (on ELF systems on the GOT).
ninjalj
A: 

Search TLB and cache. But for just small answer, in these small codes, cache effects the execution time. For large codes, besides the cache, many memory pages will be swapped out and for later usage swapped in from hard disk to your ram. So when you use a part of code very often it will not be swapped out and thus it's execution time is enhanced.

Green Code