Obviously you should choose a binding that suits your transport needs, for example if you need security or transaction support then you will need to add that. If you want peak performance its also likely that you would go for a lighter weight communications stack than WCF and possibly maybe even not use the TCP/IP protocol at all in the most extreme cases.
The following results were obtained by running a modified version of Rick's code :-
NetTcpBinding Payload Size: 35000, Iterations: 1 Binding Elements: System.ServiceModel.Channels.TransactionFlowBindingElement System.ServiceModel.Channels.BinaryMessageEncodingBindingElement System.ServiceModel.Channels.WindowsStreamSecurityBindingElement System.ServiceModel.Channels.TcpTransportBindingElement Results (milliseconds): 10 CustomBinding (HTTP/Binary/ReliableSession(ordered)/NoSecurity) Payload Size: 35000, Iterations: 1 Binding Elements: System.ServiceModel.Channels.ReliableSessionBindingElement System.ServiceModel.Channels.BinaryMessageEncodingBindingElement System.ServiceModel.Channels.HttpTransportBindingElement Results (milliseconds): 9 CustomBinding (TCP/Binary/NoSecurity) Payload Size: 35000, Iterations: 1 Binding Elements: System.ServiceModel.Channels.BinaryMessageEncodingBindingElement System.ServiceModel.Channels.TcpTransportBindingElement Results (milliseconds): 6
It appears at least in this simple case that the number of BindingElements is the limiting factor on performance.
Example code here.
Based on Rick Rainey's original work.