Author p-ganssle
Recipients belopolsky, p-ganssle
Date 2017-12-21.21:51:14
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
In the addition of the `fromisoformat()` alternate constructor (bpo-15873:, I noted that I was able to get some significant speedup by special-casing the `datetime` baseclass in the C code so that it bypasses the Python constructor, by replacing code that looks like this:

    return PyObject_CallFunction(cls, "iii", year, month, day);

With code that looks like this:

    PyObject *result;
    if ( (PyTypeObject *)cls == & PyDateTime_DateType ) {
        result = new_date_ex(year, month, day, (PyTypeObject *)cls);
    } else {
        result = PyObject_CallFunction(cls, "iii", year, month, day);

    return result;

(This is for `date`, but the results are even more striking for `datetime`).

In my initial proof of concept implementation of a `new_date_subclass_ex` method, I've seen (this is not compiled with optimizations on, mind you) speedups for the other constructors as well:

    Old constructor:
    Class: date
    constructor:        940.5ns
    date.fromordinal:   1544.8ns
    date.fromtimestamp: 1941.9ns

    Class: DateSubclass
    constructor:        1016.6ns
    date.fromordinal:   1760.3ns
    date.fromtimestamp: 2295.3ns

    With fastpath:
    Class: date
    constructor:        964.3ns
    date.fromordinal:   997.6ns
    date.fromtimestamp: 1130.2ns

    Class: DateSubclass
    constructor:        1086.9ns
    date.fromordinal:   1818.5ns
    date.fromtimestamp: 2129.9ns

As you can see, this is a fairly significant speedup in the common case with no cost in the unusual case and no change in behavior. I propose that we switch over all the C constructors where it makes sense to do so in date, time and datetime.

I'll have a PR forthcoming soon.
Date User Action Args
2017-12-21 21:51:14p-gansslesetrecipients: + p-ganssle, belopolsky
2017-12-21 21:51:14p-gansslesetmessageid: <>
2017-12-21 21:51:14p-gansslelinkissue32403 messages
2017-12-21 21:51:14p-gansslecreate