CODEWITHSUNDEEP
c++stlperformancecounter
Stylus
Stylus

Reputation: 19

Timing STL Containers - Wide Variation?

I'm using the following method to time some operations on STL containers vector, deque, list, multiset, and multimap.

PrecisionTimer::PrecisionTimer()
{
   LARGE_INTEGER cps;
   LARGE_INTEGER init_cnt;

   QueryPerformanceCounter( &init_cnt );
   QueryPerformanceFrequency( &cps );

   start_count = init_cnt.QuadPart;
   microseconds_per_count = 1000000.0 / cps.QuadPart;
}

void PrecisionTimer::ReStart()
{
   LARGE_INTEGER init_cnt;
   QueryPerformanceCounter( &init_cnt );
   start_count = init_cnt.QuadPart;
}


// in microseconds
unsigned int PrecisionTimer::ElaspedTime() const
{
   LARGE_INTEGER cnt;
   QueryPerformanceCounter(&cnt);
   return (unsigned int)( ( cnt.QuadPart - start_count ) 
                         * microseconds_per_count + 0.5 );
}

The process is simply this: I have a listbox full of strings, move them to a vector, and then add elements from the vector to the STL container. Then I remove all of the elements from the container and receive the time it took in microseconds.

My question is about variation: Sometimes my trial is 60,000+ microseconds different than the first one. Why? Is it to do with the timer implementation? I've been pointed in the direction of effects of timeslicing and high-speech cache. Can anyone elaborate on that? Does CPU usage affect it?

I'm not asking for a better implementation of a timer. I'm asking why it varies.

Upvotes: 1

Views: 96

Answers (1)

enhzflep
enhzflep

Reputation: 13089

Simply put, there are a small number of cpu cores in the system, yet there are a large number of processes running simultaneously. In order to achieve this, the OS will allocate time to a process before doing the same for the next one and so on. Depending on what programs are doing, they may need none-of, some-of or all-of their time-slice. As this varies, as can the number of processes running, you can have a variable period of time between each time your code is called - which when combined with constant execution time of your own code, leads to a different number of seconds elapsed on the wall-clock from when you started your program up until the time that it completes.

Since the QueryHighPerformance function returns time elapsed on the wall-clock, it doesn't take into account these differences in scheduling and thus it reports a varying quantity as the time required to execute the same code with the same data. The ideal timer would return the time consumed by your process only - much like the "CPU Time" column available in the Win7 Task Manager (View->Select Columns-> CPU Time)

Upvotes: 1

Related Questions