Data Container Profiling


This page provides some interesting results from profiling different container implementations. The profiling was done with some simple container implementations and a small standalone program outside the Gaudi framework. The main reason for not doing it inside Gaudi (yet) was to obtain some results quickly. However, this also allows to obtain some basic results without having to worry about possible side effects from the framework. The next step will be to repeat the exercise inside Gaudi, including data containers provided by the framework.

The Container Implementations

Six different data containers were implemented:

  • ContArrayStatKeepAssign
  • ContArrayStatProtectedKeepAssign
  • ContStdVector
  • ContStdVectorKeepAssign
  • ContStdVectorNew
  • ContStdVectorPlacementNew

Each container implements three methods: reset(), append(const T&) and get(unsigned int). The reset() method prepares the container for the next event, append() adds a data instance to the container and get() allows access by index. With the exception of the first two, containers are constructed with an initial capacity which is increased if necessary during the test run. The two array based implementations have a fixed capacity. All implementations are templates, allowing to exercise them with different data types. Note however, that they are not designed for real life applications but merely to wrap the underlying container in a common interface for this specific test! The different container implementations are described in more detail below.


The underlying container is a simple array allocated in the constructor using operator new []. The capacity of the array is not allowed to grow and there are no safety measures implemented. I.e. attempts to add data beyond the capacity are not intercepted and will result in a crash. The reset() method simply sets the element counter to 0. The append() method adds data by assignment and increments the element counter. This is clearly not an implementation any sane person would use. It's sole purpose is to play the role of the lower limit.


Similar to ContArrayStatKeepAssign but intercepts attempts to add data beyond capacity. Capacity is never increased, however. The append method simply issues an error message and refuses to add more data.


The most straightforward implementation. The reset() method simply wraps std::vector::clear() and append() just forwards to std::vector::push_back().


Uses a std::vector internally. But as opposed to ContStdVector manages the size of the vector itself and adds new elements by assignment.


Uses a std::vector<T*> internally. Manages the size of the vector itself. Data is added by explicitly calling operator new. Memory is freed with delete before new data is inserted but only for reused addresses. Of course all memory is freed when the container is destructed. The reset() method simply sets the element counter to 0.


Also uses a std::vector<T*> internally. But as opposed to ContStdVectorNew uses placement new. This is expected to be faster and also makes it unnecessary to call destructors in the append() method. (Well, strictly this is not true if the contained data class allocates recourses. But this is not the case with our simple Coordinate class.) Again, all memory is freed when the container goes out of scope and reset() just sets the element counter to 0.

The Profiling Procedure

I aimed for a setup that resembles the requirements in real event processing while being as lean as possible at the same time. To this end I implemented a simple data class Coordinate which holds three double data members. It features the usual accessors and constructors. This class is not really useful for anything, the point is that it is not POD and thus allows for a more realistic scenario.

The different container implementations are exercised by the class ContainerTester. This class implements a simple event loop. For each event the reset() method of all container implementations is called. A random number of Coordinate instances is created in each event. The minimum and maximum numbers of Coordinate instances in each event is configurable. The append methods of all containers are called for each instance of Coordinate in the event. In order to make all calls visible to the profiler, there is a wrapper method for each containers append() method. Otherwise inlined container specific implementations would not show up as function calls. Since there is a wrapper call for each container the comparison is fair, independent of inlining in the container implementation. Immediately after a Coordinate instance is added to the containers all containers are accessed and the retrieved value is compared to the original data. This ensures data integrity, i.e. that all containers actually do contain what they are supposed to.

A simple main() implementation instantiates a ContainerTester and calls its run() method. The callgrind tool is used for profiling. Visualisation is done using kcachegrind.

The source code of the standalone profiling suite can be downloaded here. The compiler flags used in the test are g++ -g  -O3 -c -Wall -Werror -ansi -pedantic. The test was performed on SLC 4.4 X86_64 running on a AMD64 3000+ system.


And now the ranking:

  1. ContArrayStatKeepAssign: 2.74%
  2. ContArrayStatProtectedKeepAssign, ContStdVector: 3.47%
  3. ContStdVectorKeepAssign: 6.03%
  4. ContStdVectorPlacementNew: 6.4%
  5. ContStdVectorNew: 40.54%

You can view the profiling diagram here.


As expected, the completely unprotected static array implementation is the fastest. But it only represents a lower limit and is unusable in practice. The straightforward std::vector and the array implementation with boundary check share the second place. However, the latter is less flexible since does not implement dynamic capacity.

So we arrive at the conclusion that the best solution is actually the most straightforward one, using the STL std::vector. I like that result.

-- Main.krinnert - 09 May 2007

Edit | Attach | Watch | Print version | History: r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r1 - 2007-05-09 - KurtRinnert
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    LHCb All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2021 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback