This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author skrah
Recipients ezio.melotti, loewis, skrah, vstinner
Date 2011-12-09.21:12:30
SpamBayes Score 4.5827875e-09
Marked as misclassified No
Message-id <1323465152.13.0.29944008784.issue13570@psf.upfronthosting.co.za>
In-reply-to
Content
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 calculations
and prints the result strings to a file.


Average results (10 iterations each):

Python 2.7:            5.87s
Revision 1726fa560112: 6.07s
Revision 7ffe3d304487: 6.56s


The bottleneck in telco.py is the line that writes a Decimal to the
output file:

  outfil.write("%s\n" % t)

The bottleneck in _decimal is (res is ascii):

   PyUnicode_FromString(res);

PyUnicode_DecodeASCII(res) has the same performance.


With this function ...

  static PyObject*
unicode_fromascii(const char* s, Py_ssize_t size)
{
    PyObject *res;
    res = PyUnicode_New(size, 127);
    if (!res)
        return NULL;
    memcpy(PyUnicode_1BYTE_DATA(res), s, size);
    return res;
}

... I get the same performance as with Python 2.7 (5.85s)!


I think it would be really beneficial for C-API users to have
more ascii low level functions that don't do error checking and
are simply as fast as possible.
History
Date User Action Args
2011-12-09 21:12:32skrahsetrecipients: + skrah, loewis, vstinner, ezio.melotti
2011-12-09 21:12:32skrahsetmessageid: <1323465152.13.0.29944008784.issue13570@psf.upfronthosting.co.za>
2011-12-09 21:12:31skrahlinkissue13570 messages
2011-12-09 21:12:30skrahcreate