
This issue trackerhas been migrated toGitHub, and is currentlyread-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.
Created on2017-12-21 21:51 byp-ganssle, last changed2022-04-11 14:58 byadmin. This issue is nowclosed.
| 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)*![]() | Date: 2017-12-21 21:51 | |
In the addition of the `fromisoformat()` alternate constructor (bpo-15873:https://github.com/python/cpython/pull/4699), 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.9nsAs 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)*![]() | Date: 2018-01-16 18:06 | |
New changeset9f1b7b93f5f0ef589e7b272e127cacf4ce5d23f1 by Alexander Belopolsky (Paul Ganssle) in branch 'master':bpo-32403: Faster date and datetime constructors (#4993)https://github.com/python/cpython/commit/9f1b7b93f5f0ef589e7b272e127cacf4ce5d23f1 | |||
| msg313019 -(view) | Author: Alexander Belopolsky (belopolsky)*![]() | Date: 2018-02-27 19:41 | |
New changeset5bd04f964b4f1bcdbd0fa36de04f087c2db07cfe by Alexander Belopolsky (Paul Ganssle) in branch 'master':bpo-10381,bpo-32403: What's new entries for changes to datetime (gh-5814)https://github.com/python/cpython/commit/5bd04f964b4f1bcdbd0fa36de04f087c2db07cfe | |||
| msg313021 -(view) | Author: Alexander Belopolsky (belopolsky)*![]() | Date: 2018-02-27 19:58 | |
New changesetfff596f792a0752b0e571fa57809e5752aba6353 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)https://github.com/python/cpython/commit/fff596f792a0752b0e571fa57809e5752aba6353 | |||
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2022-04-11 14:58:55 | admin | set | github: 76584 |
| 2018-02-27 19:58:30 | belopolsky | set | messages: +msg313021 |
| 2018-02-27 19:41:43 | miss-islington | set | pull_requests: +pull_request5701 |
| 2018-02-27 19:41:33 | belopolsky | set | messages: +msg313019 |
| 2018-02-22 16:33:18 | p-ganssle | set | pull_requests: +pull_request5589 |
| 2018-01-16 18:07:46 | belopolsky | set | status: open -> closed stage: patch review -> resolved |
| 2018-01-16 18:06:33 | belopolsky | set | messages: +msg310099 |
| 2017-12-23 20:02:38 | p-ganssle | set | keywords: +patch stage: patch review pull_requests: +pull_request4881 |
| 2017-12-21 21:51:14 | p-ganssle | create | |