It would be easy and safe to just use a/b = float(a)/float(b) if both a and b are less 
than 2**53 (assuming IEEE doubles).  Then there wouldn't be any loss of speed for 
small integers.

For large integers the algorithm I posted should run in time linear in the number of 
digits of max(a, b), at least in the worst case (though with appropriate optimizations 
it could be made much faster for 'random' inputs).  The current algorithm has 
essentially O(1) runtime.  

To get proper timings I'd have to code this up properly.  I'll do this, unless there's 
a consensus that it would be a waste of time :)