[issue4128] Performance regression in long division in 2.6

Changes by Martin v. Löwis <[EMAIL PROTECTED]>: -- resolution: -> wont fix status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> ___ __

[issue4128] Performance regression in long division in 2.6

Fredrik Johansson <[EMAIL PROTECTED]> added the comment: > I propose to close this as "won't fix"; I'm not interested in 150ms > speed differences when dividing 10 digit numbers. Sure. (I care about differences like this, because they have a tendency to add up. But it's a minor issue, and a

[issue4128] Performance regression in long division in 2.6

STINNER Victor <[EMAIL PROTECTED]> added the comment: > I propose to close this as "won't fix" I agree. > I'm not interested in 150ms speed differences when dividing 10 digit numbers. I'm ok to close the ticket, but I'm also interrested to optimize Python. But the compiler option is not

[issue4128] Performance regression in long division in 2.6

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: The 2.5 build was done by VS 2003, with no PGO, and the 2.6 build was done with VS 2008, and it used profile-guided optimization. To understand why it behaves the way it behaves, you probably need to look at the respective machine code. I p

[issue4128] Performance regression in long division in 2.6

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: It may be that one of the builds was done with profile-guided optimization and the other was not. If you are interested in long division performance, you may also take a look at #3451. -- nosy: +loewis, pitrou ___

[issue4128] Performance regression in long division in 2.6

Fredrik Johansson <[EMAIL PROTECTED]> added the comment: > The speed difference comes from different compiler options. I figured as much. I'm using the binaries from python.org (see the .txt file; it includes version headers). The question is why the compilation changes for 2.6 slowed down divi

[issue4128] Performance regression in long division in 2.6

STINNER Victor <[EMAIL PROTECTED]> added the comment: The source code is unchanged except the format functions (binary and octal bases with the new prefixes: 0b, 0o). The speed difference comes from different compiler options. - (Ubuntu Gutsy) python2.5: 1010 ms - python trunk: 1010 ms - pyt

[issue4128] Performance regression in long division in 2.6

New submission from Fredrik Johansson <[EMAIL PROTECTED]>: On my laptop (Windows XP, 32-bit), long division is about 15% slower in 2.6 compared to 2.5. See the attached .txt for timings. I noticed this when comparing the unit tests for mpmath (http://code.google.com/p/mpmath/) under 2.5 and 2.6.