diff options
author | Marc Glisse <marc.glisse@inria.fr> | 2020-06-19 13:03:45 +0100 |
---|---|---|
committer | Jonathan Wakely <jwakely@redhat.com> | 2020-06-19 13:03:45 +0100 |
commit | 465520e3eb45d83ad18394aa537150bfa6bdf117 (patch) | |
tree | 340811886e54c9949a5e0518310efd207db14041 /gcc/fortran | |
parent | f8f5715606a4a455327874847ccc91f4617bb4de (diff) | |
download | gcc-465520e3eb45d83ad18394aa537150bfa6bdf117.zip gcc-465520e3eb45d83ad18394aa537150bfa6bdf117.tar.gz gcc-465520e3eb45d83ad18394aa537150bfa6bdf117.tar.bz2 |
libstdc++: std::includes performance tweak
A small tweak to the implementation of __includes, which in my
application saves 20% of the running time. I noticed it because using
range-v3 was giving unexpected performance gains.
Some of the gain comes from pulling the 2 calls ++__first1 out of the
condition so there is just one call. And most of the gain comes from
replacing the resulting
if (__comp(__first1, __first2))
;
else
++__first2;
with
if (!__comp(__first1, __first2))
++__first2;
I was very surprised that the code ended up being so different for such
a change, and I still don't really understand where the extra time is
going...
Anyway, while I blame the compiler for not generating very good code
with the current implementation, I believe the change can be seen as a
simplification.
libstdc++-v3/ChangeLog:
* include/bits/stl_algo.h (__includes): Simplify the code.
Diffstat (limited to 'gcc/fortran')
0 files changed, 0 insertions, 0 deletions