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.

Title: date, time and datetime alternate constructors should take fast construction path
Type: enhancement Stage: resolved
Components: Versions: Python 3.8, Python 3.7
Status: closed Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: belopolsky, p-ganssle
Priority: normal Keywords: patch

Created on 2017-12-21 21:51 by p-ganssle, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 4993 merged p-ganssle, 2017-12-23 20:02
PR 5814 merged p-ganssle, 2018-02-22 16:33
PR 5929 merged miss-islington, 2018-02-27 19:41
Messages (4)
msg308907 - (view) Author: Paul Ganssle (p-ganssle) * (Python committer) Date: 2017-12-21 21:51
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.
msg310099 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2018-01-16 18:06
New changeset 9f1b7b93f5f0ef589e7b272e127cacf4ce5d23f1 by Alexander Belopolsky (Paul Ganssle) in branch 'master':
bpo-32403: Faster date and datetime constructors (#4993)
msg313019 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2018-02-27 19:41
New changeset 5bd04f964b4f1bcdbd0fa36de04f087c2db07cfe by Alexander Belopolsky (Paul Ganssle) in branch 'master':
bpo-10381, bpo-32403: What's new entries for changes to datetime (gh-5814)
msg313021 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2018-02-27 19:58
New changeset fff596f792a0752b0e571fa57809e5752aba6353 by Alexander Belopolsky (Miss Islington (bot)) in branch '3.7':
bpo-10381, bpo-32403: What's new entries for changes to datetime (gh-5814) (gh-5929)
Date User Action Args
2022-04-11 14:58:55adminsetgithub: 76584
2018-02-27 19:58:30belopolskysetmessages: + msg313021
2018-02-27 19:41:43miss-islingtonsetpull_requests: + pull_request5701
2018-02-27 19:41:33belopolskysetmessages: + msg313019
2018-02-22 16:33:18p-gansslesetpull_requests: + pull_request5589
2018-01-16 18:07:46belopolskysetstatus: open -> closed
stage: patch review -> resolved
2018-01-16 18:06:33belopolskysetmessages: + msg310099
2017-12-23 20:02:38p-gansslesetkeywords: + patch
stage: patch review
pull_requests: + pull_request4881
2017-12-21 21:51:14p-gansslecreate