Question

I’ve got a procedure which fills some arrays with values taken from another array.
It looks similar to the following code:

// Point 0
ptrlistVector.clear();

// Point 1
ptrlistVector.resize(50);
const size_t s = ptrlistVector.size();

// Point 2
for (ObjectList::iterator j = objList.begin(); j != objList.end(); ++j)
{
    for (UINT i = 0; i < s; ++i) 
    {
        ptrlistVector[i].push_back(&(*j)); 
    }
}
// Point 3

Actually there is more complicated code in the “push_back” line – I push different values to a list. The values depend on some condition.

Declaration s and definitions:

typedef std::list<void*> ObjectPtrList;
typedef std::vector<ObjectPtrList> PtrListVector;
typedef std::list<std::string> ObjectList;

ObjectList objList;
PtrListVector ptrlistVector;

I measured time between the points, in average numbers the point 1-0 takes 0.02 secs and the point 3-2 takes 0.05 secs.
I tried to refactor the loops and found some strange behaviour.
I replaced the loops above with the following:

for (UINT i = 0; i < s; ++i)
{
    for (ObjectList::iterator j = objList.begin(); j != objList.end(); ++j)
    {
        ptrlistVector[i].push_back(&(*j)); 
    }
}

After that the timing was changed. The point 3-2 takes 0.035 secs, but the clear() call (the point 1-0) now takes 0.45(!!!) that is much greater than the previous time.

I use MSVC 10.0, the results are approximately the same in both Debug and Release mode. In Release mode the time difference is not so significant, but anyway the time is greater for the second.

Could anyone please explain me why the clear() call takes much more time after I changed the loops?

The code below is the console application I used for my performance tests.

#include "stdafx.h"
#include <windows.h>
#include <vector>
#include <list>
#include <cstdio>
#include <cassert>
#include <string>

int _tmain(int argc, _TCHAR* argv[])
{
    typedef std::list<void*> ObjectPtrList;
    typedef std::vector<ObjectPtrList> PtrListVector;
    typedef std::list<std::string> ObjectList;

    ObjectList objList;
    objList.insert(objList.begin(), 500, std::string());

    PtrListVector ptrlistVector;

    LARGE_INTEGER __counters[10];
    double __totals[10] = { 0 };
    UINT __counter = 0;
    BOOL bRes;

    LARGE_INTEGER __freq;
    bRes = QueryPerformanceFrequency(&__freq);
    assert(bRes);

    for (int k = 0; k < 500; ++k)
    {
        // Point 0
        bRes = QueryPerformanceCounter(&__counters[0]);
        ptrlistVector.clear();

        // Point 1
        bRes = QueryPerformanceCounter(&__counters[1]);
        ptrlistVector.resize(50);
        const size_t s = ptrlistVector.size();

        // Point 2
        bRes = QueryPerformanceCounter(&__counters[2]);
        /*
        // original
        for (ObjectList::iterator j = objList.begin(); j != objList.end(); ++j)
        {
            for (UINT i = 0; i < s; ++i) 
            {
                ptrlistVector[i].push_back(&(*j)); 
            }
        }
        /*/
        for (UINT i = 0; i < s; ++i) // refactored
        {
            for (ObjectList::iterator j = objList.begin(); j != objList.end(); ++j)
            {
                ptrlistVector[i].push_back(&(*j)); 
            }
        }
        //*/

        // Point 3  
        bRes = QueryPerformanceCounter(&__counters[3]);
        __counter += 1;
        __totals[1] += 1.0 * (__counters[1].QuadPart - __counters[0].QuadPart) / __freq.QuadPart;
        __totals[2] += 1.0 * (__counters[2].QuadPart - __counters[1].QuadPart) / __freq.QuadPart;
        __totals[3] += 1.0 * (__counters[3].QuadPart - __counters[2].QuadPart) / __freq.QuadPart;
        __totals[4] += 1.0 * (__counters[3].QuadPart - __counters[0].QuadPart) / __freq.QuadPart;
        printf("%s: %.4f  %.4f  %.4f = %.4f\n", 
            __FUNCTION__, 
            __totals[1]/__counter, 
            __totals[2]/__counter, 
            __totals[3]/__counter, 
            __totals[4]/__counter);
    }
    return 0;
}

Answer 1

I want to preface this answer with a disclaimer – it’s conjecture, since I haven’t run the code in the question, nor have I looked at the actual library implementation involved. But I think this outlines a possible explanation for any statistically significant difference in the timing described in the question. But, keep in mind that it is conjecture at this point.

---

The difference in the amount of time it takes to clear the vector of lists might be due to how the heap is used and the work that might be going on when the heap is handling list elements that are freed when the lists are destroyed. I think there might possibly be more work going on in the heap when the list elements are being deallocated with the second loop type. I can only guess (I haven’t stepped through the library code).

In the first style of loop, each list gets one element added per loop iteration; in other words, loop iteration 0 puts one element on each list, then loop iteration 1 puts another element on each list, etc.

In your second example (where the clear() operation takes longer), each list gets built up separately; in other words, the list in ptrlistVector[0] gets filled, then ptrlistVector[1] gets filled and so on.

I’d guess that for the first loop style, each element on a particular list is not consecutive (in address space) to other elements on the list. That would be because in the time between any two push_back() operations on a particular list, 50 other allocations occurred to add elements to other lists.

However, I’d guess that in the second loop style, the elements in a particular list are more or less consecutive, since that’s the order that the allocations occurred.

Now, let’s think about what that might mean when a list is being destroyed (as will happen when the vector holding the lists is cleared). For a list where the elements are consecutive in address space, the heap might be spending a bunch of time coalescing those adjacent free blocks. But when a list that has a bunch of elements that aren’t adjacent frees its elements, the freed memory blocks aren’t adjacent, so no coalescing can occur. It won’t be until we get to the last (or last few) lists that the heap might start to see adjacent free blocks of memory that can be coalesced.