EASTL performance

Question

Today I downloaded and created a sample project of the Electronic Arts STL implementation and the EA's vector is looks much slower for me than the standard. I just created 2 vectors and uploading them with 1 million of items:

void performance_test(void)
{
    clock_t start;
    clock_t end;


    // EA

    eastl::string strEA = "hello";
    eastl::vector<eastl::string> vec_EA;

    start = clock();
    for (size_t i = 0; i < 1000000; i++)
    {
        vec_EA.push_back(strEA);
    }

    end = clock();
    printf("EA       %f\n", (double(end - start) / 1000));

    // Standard

    std::string strStandard = "hello";
    std::vector<std::string> vec_Standard;

    start = clock();
    for (size_t i = 0; i < 1000000; i++)
    {
        vec_Standard.push_back(strStandard);
    }

    end = clock();
    printf("Standard %f\n", (double(end - start) / 1000));
}

And the results are:

1. EA 0.759000
2. Standard 0.064000

So, is there anything what I'm doing wrong or I just missed something? The sample has been compiled with v100 platform toolset.

Answer 1

When I run your benchmark with a release build in VS 2010, I get results similar to what one might hope for:

EA       0.063000
Standard 0.073000

However, when I run the same release build under the VS debugger, the results change dramatically:

EA       1.293000
Standard 0.080000

And it takes even longer (tens of seconds) for whatever object cleanup occurs. Keep in mind - this is the same release mode build, not a debug build.

I haven't looked into why EASTL is impacted so severely by the debugger environment. I assume it has something to do with the debug heap.

---

Update (4 March 2015):

Another detail that affects the results is the length of the string involved. VS uses a 'short string optimization' in std::string which will reduce the number of allocations that occur for string objects that have a value like "hello". If you change the initialized value for the strings used in the example from "hello" to "hello - but not too short", you'll get results more like the following:

// release build, run outside of the debugger
EA       0.078000
Standard 0.113000

// release build, run under the debugger
EA       0.762000
Standard 1.414000

And now it becomes evident that the order of magnitude difference when the benchmark is run under the debugger is likely due to the debug heap spending a lot of time tracking the string memory allocations.