Re: [Boost-users] Detecting memfun staticness

From: JOAQUIN M. LOPEZ MUÑOZ (joaquin_at_[hidden])
Date: 2008-08-25 10:45:46

________________________________________
De: boost-users-bounces_at_[hidden] [boost-users-bounces_at_[hidden]] En nombre de Markus Werle [numerical.simulation_at_[hidden]]
Enviado el: lunes, 25 de agosto de 2008 16:03
Para: boost-users_at_[hidden]
Asunto: Re: [Boost-users] Detecting memfun staticness

> <joaquin <at> tid.es> 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