[Tim] >> I assume it's the overflow-checking that's the major time sink,
[Adam Olsen] > Are you sure? No -- that's what "assume" means <0.7 wink>. For example, there's a long chain of function calls involved in int(string) too. > <https://sourceforge.net/tracker/index.php?func=detail&aid=1334979&group_id=5470&atid=305470> > > That patch removes the division from the loop (and fixes the bugs), > but gives only a small increase in speed. As measured how? Platform, compiler, input, etc? Is the "ULONG_MAX / base" part compiled to inline code or to a call to a library routine (e.g., if the latter, it could be that a dividend with "the sign bit set" is extraordinarily expensive for unsigned division -- depends on the <compiler, HW> pair in use)? If so, a small static table could avoid all runtime division. If not, note that the number of divisions hasn't actually changed for 1-character input. Etc. In any case, I agree it _should_ fix the bugs (although it also needs new tests to verify that). _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com