Commit Graph

19 Commits

Author SHA1 Message Date
Victor Stinner b6ed57d980 Use _PyObject_CallMethodIdObjArgs() in _asyncio
Issue #28915: Replace _PyObject_CallMethodId() with
_PyObject_CallMethodIdObjArgs() when the format string was only made of "O"
formats, PyObject* arguments.

_PyObject_CallMethodIdObjArgs() avoids the creation of a temporary tuple and
doesn't have to parse a format string.
2016-12-09 14:24:02 +01:00
Victor Stinner f17c3de263 Use _PyObject_CallNoArg()
Replace:
    PyObject_CallFunctionObjArgs(callable, NULL)
with:
    _PyObject_CallNoArg(callable)
2016-12-06 18:46:19 +01:00
Victor Stinner a5ed5f000a Use _PyObject_CallNoArg()
Replace:
    PyObject_CallObject(callable, NULL)
with:
    _PyObject_CallNoArg(callable)
2016-12-06 18:45:50 +01:00
Victor Stinner 7bfb42d5b7 Issue #28858: Remove _PyObject_CallArg1() macro
Replace
   _PyObject_CallArg1(func, arg)
with
   PyObject_CallFunctionObjArgs(func, arg, NULL)

Using the _PyObject_CallArg1() macro increases the usage of the C stack, which
was unexpected and unwanted. PyObject_CallFunctionObjArgs() doesn't have this
issue.
2016-12-05 17:04:32 +01:00
Victor Stinner de4ae3d486 Backed out changeset b9c9691c72c5
Issue #28858: The change b9c9691c72c5 introduced a regression. It seems like
_PyObject_CallArg1() uses more stack memory than
PyObject_CallFunctionObjArgs().
2016-12-04 22:59:09 +01:00
Yury Selivanov edfe8869c8 Merge 3.6 (issue #28843) 2016-12-01 11:37:47 -05:00
Victor Stinner 27580c1fb5 Replace PyObject_CallFunctionObjArgs() with fastcall
* PyObject_CallFunctionObjArgs(func, NULL) => _PyObject_CallNoArg(func)
* PyObject_CallFunctionObjArgs(func, arg, NULL) => _PyObject_CallArg1(func, arg)

PyObject_CallFunctionObjArgs() allocates 40 bytes on the C stack and requires
extra work to "parse" C arguments to build a C array of PyObject*.

_PyObject_CallNoArg() and _PyObject_CallArg1() are simpler and don't allocate
memory on the C stack.

This change is part of the fastcall project. The change on listsort() is
related to the issue #23507.
2016-12-01 14:43:22 +01:00
Benjamin Peterson 996fc1fcfc correctly emulate error semantics of gen.throw in FutureIter_throw 2016-11-14 00:15:44 -08:00
Yury Selivanov 692796a948 Issue #26081: Fix refleak in _asyncio.Future.__iter__().throw. 2016-11-08 19:04:57 -05:00
Serhiy Storchaka 60e49aa756 Issue #23996: Added _PyGen_SetStopIterationValue for safe raising
StopIteration with value. More safely handle non-normalized exceptions
in -_PyGen_FetchStopIterationValue.
2016-11-06 18:47:03 +02:00
Victor Stinner f94d1eee74 Issue #28544: Fix inefficient call to _PyObject_CallMethodId()
"()" format string creates an empty list of argument but requires extra work to
parse the format string.
2016-10-29 09:05:39 +02:00
Yury Selivanov 684ef2c888 Issue #28544: Pass `PyObject*` to _PyDict_Pop, not `PyDictObject*` 2016-10-28 19:01:21 -04:00
Victor Stinner 1aea8fb9e0 Issue #28544: Fix _asynciomodule.c on Windows
PyType_Ready() sets the reference to &PyType_Type.

&PyType_Type cannot be resolved at compilation time (not on Windows?).
2016-10-28 19:13:52 +02:00
Yury Selivanov a0c1ba608e Issue #28544: Implement asyncio.Task in C.
This implementation provides additional 10-20% speed boost for
asyncio programs.

The patch also fixes _asynciomodule.c to use Arguments Clinic, and
makes '_schedule_callbacks' an overridable method (as it was in 3.5).
2016-10-28 12:52:37 -04:00
INADA Naoki 74c17539f2 Issue #28430: Fix iterator of C implemented asyncio.Future doesn't
accept non-None value is passed to it.send(val).
2016-10-25 19:00:45 +09:00
Yury Selivanov 53478f8c6d Issue #28493: Fix typos in _asynciomodule.c
Thanks to Stéphane Wirtel!
2016-10-20 16:33:19 -04:00
Yury Selivanov a4b884f900 Issue #28492: Fix how StopIteration is raised in _asyncio.Future 2016-10-20 15:54:20 -04:00
INADA Naoki c411a7d821 Issue #28452: Remove _asyncio._init_module function 2016-10-18 11:48:14 +09:00
INADA Naoki 9f2ce25481 Issue #28428: Rename _futures module to _asyncio.
It will have more speedup functions or classes other than asyncio.Future.
2016-10-15 15:39:19 +09:00