A 2-3% timing difference probably isn't reliably repeatable in real code.
My timing tests were interleaved as I swapped in various algorithms and recompiled and the time differences were consistent. I gave ranges not averages to give a feel for the "experimental error".
I'm not sure, though, if this negates your point, Beman. Something that gives a 2-3% speedup for one Boost user might not be worth any level of obfuscation unless we can prove it provides a similar speedup for other Boost uses.
Just to avoid confusion for people joining this thread halfway, the 2-3% speedup was in my code; I wasn't proposing obfuscating any boost library.
My point was that I got this speed-up by overriding operator new/delete with one-liners in just a single class (of course I chose the class I new from profiling was making heaviest use of new/delete):
void* operator new(std::size_t sz){
return boost::detail::quick_allocator<T>::alloc(sz);
}void operator delete(void *p,std::size_t sz){
boost::detail::quick_allocator<T>::dealloc(p,sz);
}where T is the name of my class. That is so easy it is practically free, like using -O3 instead of -O2.
> In our project, a 3% speed increase is considered a cause for celebration. > ....
- sped up JavaScript iBench by 70% by using a better sort algorithm and reducing the number of UString allocations
How did you celebrate that one then? :-)
Darren
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
