This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: The performance of <algorithm>.


>Well, I never bought the "An Inline Function is As Fast As a Macro" rumor.
>But still, an experiment using std::for_each shows rather disturbing
>results.  Given
>    struct A { virtual void someaction(); };
>can anybody give an easy explanation why
>    for_each(av.begin(), av.end(), mem_fun(&A::something));
>blows up the size of the compiled code by a factor of two compared to the
>straightforward implemenation?  (Even when one hacks for_each to be
>inlined?  (BTW, why isn't it inlined?))

If you could provide more detail, it would be helpful. 

When you post code that describes your issue in the future, please post
complete examples that can be cut-and-pasted to a buffer and compiled
without additional tweaking. Although this might seem idiotic to you, it
will help focus people on the exact issue that you are investigating.

When you do this, include both the "straightforward implementation" and
the test code.

>Maybe this is a more general question: I recently got the impression that
>it does not seem possible to code efficiently using GCC's <functional> and
><algorithm> in contradiction to what all the books seem to claim.  Is that
>gonna change some day?

Well, if we can make the runtime better via feedback like yours, we'll
do it. If this turns out to be a compiler issue (inlining seems to
change with every release, so perhaps it's fixed in mainline with
unit-at-a-time) then you might have to file an optimization PR in
bugzilla.

best,
benjamin


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]