By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,639 Members | 2,262 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,639 IT Pros & Developers. It's quick & easy.

Performance of static member function versus functor

P: n/a
In generic programming, static member functions and functors seem to
be very useful. I've noticed that some libraries take the approach of
using templated static member functions to provide generic
functionality, while others use functors. Take for example the
std::string char_traits class. Here, a static member "eq" is defined
to serve as a generic binary comparison function.

My implementation defines it as;

static bool eq(const char_type& c1, const char_type& c2) { return c1
== c2; }

An alternative would be to define eq as a functor, like:

struct eq {
bool operator() (const char_type c1, const char_type c2) { return
c1 == c2; }
}

The major difference, of course, is that the second case requires you
to instantiate the object. I originally thought that there wasn't
much difference, in terms of the actual assembly code generated,
between these two options. But benchmarking tests I've conduct show
that using an instantiated object is almost always faster than using a
static member function. I would have actually thought the opposite
would be true, because with an instantiated object you have the slight
additional overhead of constructing the object, whereas a static
member function is just like calling a global function.

But it seems that instantiated objects outperform static member
functions by a significant amount. My question is, is there some
inherent reason for this, or is this likely to be different from
compiler to compiler? Perhaps static member functions can't be
inlined.

Aug 14 '07 #1
Share this Question
Share on Google+
3 Replies


P: n/a

<ch******@gmail.comwrote in message...
>
An alternative would be to define eq as a functor, like:

struct eq {
bool operator() (const char_type c1, const char_type c2) { return
c1 == c2; }
}

The major difference, of course, is that the second case requires you
to ** instantiate the object. **
See if this will compile for you.

// #includes here <cstdlib>, <iostream>, <vector>, <algorithm>,etc.

struct MyRand{
int operator()(){ return std::rand() % 100;}
};

int main(){
std::vector<intvLf;
std::generate_n( std::back_inserter( vLf ), 1000, MyRand() );
// or is that what you meant by 'instantiate'

std::vector<int>::const_iterator it =
std::max_element(vLf.begin(), vLf.end());
std::cout<<"vector<intvLf.size()"<<vLf.size()
<<" The largest element is "<<*it<<std::endl;
return 0;
} // main()

Maybe I mis-understood.
--
Bob R
POVrookie
Aug 14 '07 #2

P: n/a
Hi!

ch******@gmail.com schrieb:
But it seems that instantiated objects outperform static member
functions by a significant amount. My question is, is there some
inherent reason for this, or is this likely to be different from
compiler to compiler? Perhaps static member functions can't be
inlined.
When passing a (static) function to i.e. std::for_each, you get an
instantiation of for_each, which takes a function pointer as an
argument. So each element is processed by calling a function through a
pointer.

When passing a class instance (a functor) to std::for_each, you get an
instantiation for just that specific class. Each element is process by
an inlined operator().

Usually the compiler does not optimize the (const) function pointer. It
might do so, however. That's why small functors outperform the static
function.

Frank
Aug 14 '07 #3

P: n/a
joe
On Aug 14, 1:32 pm, chsal...@gmail.com wrote:
But it seems that instantiated objects outperform static member
functions by a significant amount. My question is, is there some
inherent reason for this, or is this likely to be different from
compiler to compiler? Perhaps static member functions can't be
inlined.
Usually small functors like that can be inlined and therefore generate
more efficient code. If your functor had state and your function used
it for something fairly complicated, you might not see such an
improvement, but a vast majority of the time, you will.

joe

Aug 15 '07 #4

This discussion thread is closed

Replies have been disabled for this discussion.