PERF: low-hanging fruit in pd.merge() code
I recently had a look at this code and spotted some potential improvements to be made.
1. When the user specifies `sort=False` (the default), the code
   still performs an interim sort on the keys (the arg isn't passed down), That
   can be probably be omitted without harm.
   This is fairly trivial to do, just requires some testing.
2. Wes came up with a really lovely "counting-sort"-like trick for matching 
   up keys from each frame when the join is performed on more then one
   column. Basically, he treats each tuple of keys as being totally-ordered
   based a cartesian product (forgive me... the code is clearer).
   However, this only works as long as the size of the keyspace fits
   inside platform int, for larger keyspaces (less common since it requires
   many columns with many distinct keys each) he reverts to an algo which
   proves much slower (zipping together the keys). I think there might be a 
   faster way to code this slow-path (perhaps by binning or some other 
   cleverness). Using python bignums instead of platform int seems to hurt 
   perf too much to make it worthwhile.
3. When performing an `inner`, `left` or `right` join, a `factorize`
   is performed fully on all keys of both frames. In the case where
   dataframe sizes are highly asyemmtric (df1 >> df2), many of the
   keys for the larger frame will potentially be discarded, if they
   have no corresponding keys in the smaller frame. Marking those
   keys with a sentinal (or discarding beforehand in some other way, perhaps
   a masked array?) can reduce the working set significantly. klib uses open-addressing so the sentinal can generate lots of collisions, but
   I've still seen about 30% improvement in some cases.
   If leveraging this "wasted work" can be used to reduce the keyspace 
   significantly, it makes it more likely that the slow path mentioned in 2)
   can be avoided which can make a significant difference (2x or more).

I've played with this and have seen some real perf boosts but I won't be able to do this properly
 any time soon.
If there's anyone interested in algos who'd like to take this on and work through the subtleties (NaNs', Perhaps having to unshare some routines) you're more then welcome to give it a go.
