Nick Coghlan wrote: > Martin v. Löwis wrote: >>> In the slow example given, only one of the returned items needs to be a >>> long >> >> This is Py3k. They are all longs. > > Not inside the object they aren't
Right, inside, they are longs - but the *returned items* are all longs. > One way to optimise this (since all we need to support here is counting > rather than arbitrary arithmetic) would be for the longrange iterator to > use some simple pure C fixed point arithmetic internally to keep track > of an arbitrarily long counter, and only convert to a Python long when > it has to (just like the optimised shortrange iterator). > > I'm not sure it is worth the hassle though. What simple pure C fixed point arithmetic would you be thinking of? The long type *is* a pure C fixed point arithmetic. There are perhaps some simplifications possible to longrangeiter_next possible, e.g. it doesn't need to perform a multiplication, but could just add the step each time. Also, it could cache the value 1 in a global variable, rather than creating a fresh one each time. Other than that, I cannot imagine why another fixed point arithmetic might be significantly faster. Regards, Martin _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
