Martin v. Löwis mar...@v.loewis.de added the comment:
It's reasonable that string % formatting might have become slower...
I wonder what the issue is at this point. Unless you can state a clear issue
that you want to see resolved, I propose to close this report as invalid.
--
Stefan Krah stefan-use...@bytereef.org added the comment:
Sorry, the title of the issue isn't correct any more. The revised
issue is that in 3.3
a) outfil.write(%s\n % t)
is about 11% slower than in Python2.7 and 8% slower than in Python3.2.
On the other hand in 3.3 the hack
b)
Antoine Pitrou pit...@free.fr added the comment:
But if I understand correctly, the slowdown in string formatting is
expected, so we can indeed close this.
Well, expected doesn't mean it shouldn't be improved, so finding a way to speed
it up would be nice ;)
(probably difficult, though)
STINNER Victor victor.stin...@haypocalc.com added the comment:
Le 09/12/2011 22:12, Stefan Krah a écrit :
The bottleneck in _decimal is (res is ascii):
PyUnicode_FromString(res);
PyUnicode_DecodeASCII(res) has the same performance.
With this function ...
static PyObject*
Stefan Krah stefan-use...@bytereef.org added the comment:
I prefer to not expose such function or someone will use it without
understanding exactly how dangerous it is.
OK. - I'm afraid that I made an error in the benchmarks, since I
accidentally used a changed version of telco.py, namely:
New submission from Stefan Krah stefan-use...@bytereef.org:
I just ran the telco benchmark ...
http://www.bytereef.org/mpdecimal/quickstart.html#telco-benchmark
... on _decimal to see how the PEP-393 changes affect the module.
The benchmark reads numbers from a binary file, does some
Changes by Jesús Cea Avión j...@jcea.es:
--
nosy: +jcea
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13570
___
___
Python-bugs-list mailing list
