[issue1045] Performance regression in 2.5

Changes by Raymond Hettinger: -- resolution: -> wont fix status: open -> closed __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing

[issue1045] Performance regression in 2.5

Raymond Hettinger added the comment: FWIW, the 2.4 to 2.5 timing difference came from renaming __len__ to __length_hint__. This was at Guido's request so that the value of bool (iter(obj)) would always be True. The consequence of the change was that we lost the fast slot lookup for __len__ an

[issue1045] Performance regression in 2.5

Raymond Hettinger added the comment: I'll take a look at it next week -- want to think through the various cases. The current setup provides nice speedups when the length_hint is available. Possibly, it may be worthwhile to skip that check when the input is a generator. For the most part, I

[issue1045] Performance regression in 2.5

Amaury Forgeot d'Arc added the comment: The slowdown is due to the new function _PyObject_LengthHint: on my Win2K machine, the command python -m timeit "tuple(1 for _ in xrange(3))" answers: 10 loops, best of 3: 4.14 usec per loop By adding a line "return rv;" on the second line of _PyOb

[issue1045] Performance regression in 2.5

Changes by Raymond Hettinger: -- assignee: tim_one -> rhettinger nosy: +rhettinger __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailin

[issue1045] Performance regression in 2.5

Changes by Sean Reifschneider: -- assignee: -> tim_one nosy: +tim_one priority: -> normal __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-li

[issue1045] Performance regression in 2.5

Georg Brandl added the comment: May this be a byproduct of the new generator features in 2.5? -- nosy: +georg.brandl __ Tracker <[EMAIL PROTECTED]> __ _

[issue1045] Performance regression in 2.5

Gabriel Genellina added the comment: I've narrowed the problem to the usage of generator expressions. Generator expressions appear to be MUCH slower on 2.5 than on 2.4. >python -m timeit "tuple([1 for _ in xrange(3)])" 2.4 -> 2.23us 2.5 -> 2.31us (a bit slower, but not so much) >python -m time

[issue1045] Performance regression in 2.5

New submission from Andreas Kloeckner: The attached program uncovers a two-fold performance regression in Python 2.5 with respect to Python 2.4. Below, the "element-wise" case goes from 2.5 seconds in 2.4 to about 4 in 2.5. Since that's a pretty serious increase, I thought I'd point it out. $ py