[boost] [type_erasure] Performance

Subject: [boost] [type_erasure] Performance
From: Julien Nitard (julien.nitard_at_[hidden])
Date: 2012-07-31 10:42:28

Hi all,

I took time to write a simple benchmark for boost::any. Please find
the code attached. It requires C++11. I could only test with g++
because clang 3.0/Ubuntu segfaults on the code.

I'd be more than happy to get feedback on whether the tests are
relevant. I think the compiler can't impact the result by optimizing
away the payloads because there's the virtual call barrier preventing
it from doing so.

The results are quite good for a library that is not optimized yet.
Here are some typical results on my machine (though results may vary
slightly on each run):
Times are in seconds for 100 million iterations, using -O3 -std=c++0x
and no other special flags.

* Classic inheritance replacement:
Inherited: 0.261134
Erased: 0.260092
Erased + ctor: 0.343596
Erased + ctor 3 concepts: 0.295584

* boost::function replacement:
boost::bind: 0.260356
boost::function: 0.469181
std::function: 0.515477
te::any + boost::bind: 0.494241
te::any + lambda: 0.379945

Basically that means that TypeErasure has a cost that's zero or at
worse neglectible when compared to normal inheritance. It probably
means that those simple use cases can't be optimized since the
theoretical performance is achieved.
If you create the any object each time, then there's something like a
30% loss. That's against an empty virtual function which means that
for non trivial payloads the cost is still low. Good job !
The only thing I can't explain is why creating an any with 3 concepts
in an mpl::vector is faster than a single primitive concepts. Any
ideas ?

Nice as well is that callable<> matches or bests boost::function in
the simple cases I have tested (likely to be common thanks to C++
lambdas). Actually, I guess that the results would be even better in
"normal" circumstances because the way I wrote the test any has 2
virtual call to perform.
I guess that in that case again, optimization is not required before
acceptance and release.

Regards,

Julien