________________________________________ De: boost-users-bounces@lists.boost.org [boost-users-bounces@lists.boost.org] En nombre de Markus Werle [numerical.simulation@web.de] Enviado el: lunes, 25 de agosto de 2008 16:03 Para: boost-users@lists.boost.org Asunto: Re: [Boost-users] Detecting memfun staticness
writes: And now I'd like to optimize call_f's implementation by avoiding the creation of the T object when it is not necessary (as in bar, whose memfun f is static).
IMHO this is unnecessary if you are only interested in avoiding the small object instatiation. I expect the compiler to erase them.
That's what I also expected... until proven wrong by real life :( This has come up as part of my work for the post-review version of Boost.Flyweight: going from t.f(x) to T::f(x) in one critical part of the library resulted in a release mode 3x speedup when accessing the values associated to flyweight objects. This was with MSVC++ 8.0, which I consider rather good at optimizing chores. With GCC 3.4 for Cygwin the differences are even higher. The "t" in "t.f(x)" looks clearly droppable (it does not take part in the evluation of f(x)), but the compiler refuses to do the optimization. FWIW, that "t" is not constructed on every call but merely a reference to it is recovered via a singleton API. This singleton is implemented as a Meyers singleton, i.e. as a static local object, which as you know makes the compiler generate initialization code to construct the local object the first time the context is entered; I wonder whether this side effect is what's preventing the compiler from omitting the reference recovering altogether.
OTOH this remains an interesting question: Might be useful if you want to ensure to grab only those classes with the static version for reasons other than runtime performance.
If you have a clue I'd love to hear about it :) Joaquín M López Muñoz Telefónica, Investigación y Desarrollo