search/search_n vs find/find_if

[Chris Jefferson]

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