This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: search/search_n vs find/find_if
Paolo Carlini wrote:
Chris Jefferson wrote:
This is actually very slightly harder than I thought at first... as
find is optimised for char types.. therefore it might be necessary to
catch if find_if is being given our special comparison object and if
so pass it back to find.. however I'm going to investigate to see a)
how much speed benefit is actually given by the char specialisations
of find and b) how messy it looks delegating find_if to find :)
Sorry, but I don't understand (I was tempted to write "Huh?!?", but
someone explained time ago that it's considered unpolite, so... ;) Which
optimization?!? Find or fill?!?
No, you could have said "Huh?!?"
As soon as I'd sent this (but it only just appeared on this list for me,
along with your reply) I realised I had been suffering brain freeze...
What was worrying me was that I knew some functions (fill and copy it
turns out) have efficent specialisations, which I assumed would not
exist in the predicated versions, and therefore we might be losing some
performance. However now I look more carefully, there is no such case,
the only "type specific" specialisations are for fill, copy and
lexicographic_compare (which we haven't disturbed from before)
Therefore my current plan goes something like:
1) Check through all the previously simplified algorithms for anywhere
where the non-predicate version uses find and the predicate version
doesn't use find_if, and knock out some test cases.
2) Try delegating find, count, replace, replace_copy, remove_copy and
remove to find_if, count_if, replace_if, replace_copy_if, remove_copy_if
and remove_if (while of course adding test cases). I've looked at the
tree output and x86, and they are very close (the assembler isn't
identical, but only differs when entering / leaving a function. I hope
to try to figure out why..)
Chris