random.randint() slow, esp in Python 3

[Ian Kelly]

On Sat, Sep 24, 2011 at 12:55 AM, Steven D'Aprano
<steve+comp.lang.python at pearwood.info> wrote:
> If you want unbiased, random (or at least pseudo-random) integers chosen
> from an uniform distribution with proper error checking, you should use
> randint or randrange.
>
>
>> but if you just
>> want a pile of more-or-less random integers, int(random.random()*top)
>> is the best option.
>
> "I only need random-ish ints, but I need 'em yesterday!!!"
>
> If you want biased, not-quite-uniformly distributed integers with no error
> checking, then the above will save you a few nanoseconds per call. So if
> your application needs a million such ints, you might save a full five
> seconds or so. Sounds like premature optimization to me, but what do I
> know? If you have an application where the quality of randomness is
> unimportant and generating random ints is a genuine performance bottleneck,
> then go right ahead.

Peeking under the hood, after all the error-checking and extra
features, randrange basically just does int(random.random() * top).
Any bias present in the latter will also be present in the former.

Cheers,
Ian