On Dec 7, 4:08 pm, "Joe Goldthwaite" <[EMAIL PROTECTED]> wrote:
> Here's the simple benchmark;
>
> start = time.time()
> for x in xrange(3):
> for y in xrange(10000000):
> pass
> print 'xRange %s' % (time.time() - start)
>
> start = time.time()
> for x in range(3):
> for y in range(10000000):
> pass
> print 'Range %s' % (time.time() - start)
>
> Here's what I get;
>
> xRange 92.5529999733
> Range 95.2669999599
>
> Not a lot of difference.
Try this:
start = time.time()
for x in xrange(3):
for y in xrange(10000000):
if y == 10:
break
print 'xRange %s' % (time.time() - start)
start = time.time()
for x in range(3):
for y in range(10000000):
if y == 10:
break
print 'Range %s' % (time.time() - start)
> Range is slower but not by much. I know that range
> builds
> a list then iterates through it. I thought that xrange just kept a counter
> that was
> incremented and returned with each call. No list was ever created. If that's
> true
> (and I guess it's not), xrange would be much faster than range. It seems
> almost
> identical.
xrange doesn't merely return a counter. It creates an int object and
returns it, which is somewhat more expensive. The time required to
create ten million integer objects dwarfs the time required to
allocate a single list with ten million entries, and this cost occurs
with both range and xrange, unless you break early.
> Given the amount of performance difference, I don't see why
> xrange even
> exists.
To keep memory use down. It's pointless and wasteful to allocate
about 160 megabytes (or 1 kilobyte) of data to store a list when you
only need 36 or so of those bytes at any given time.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
