Nick Coghlan wrote:
Many of the routines in abstract.c check their parameters for NULL, as a
sanity check, and throw a SystemError if NULL is detected. I'm tempted
to suggest making these checks only when Py_DEBUG is defined, but I
suspect if you wanted it that way, you would have changed it
Hrvoje Niksic hrvoje.niksic at avl.com writes:
Agreed, and more importantly, I have yet to be convinced that those NULL
checks introduce a measurable slowdown. Daniel, have you tried
measuring the performance difference with only the NULL checks removed?
I think it would be fine to add a
Agreed, and more importantly, I have yet to be convinced that those NULL
checks introduce a measurable slowdown. Daniel, have you tried
measuring the performance difference with only the NULL checks removed?
I think it highly unlikely that there is a performance difference.
These tend to
Raymond Hettinger python at rcn.com writes:
-1
The API confusion and clutter isn't worth the micro-optimization.
The API wouldn't change, there would only be a short path for long-indexing of
lists, exactly as there is today in 2.x's BINARY_SUBSCR implementation.
On Tue, Mar 24, 2009 at 4:30 AM, Hrvoje Niksic hrvoje.nik...@avl.comwrote:
Agreed, and more importantly, I have yet to be convinced that those NULL
checks introduce a measurable slowdown. Daniel, have you tried measuring
the performance difference with only the NULL checks removed?
I'll
On Tue, Mar 24, 2009 at 7:30 AM, Daniel Stutzbach
dan...@stutzbachenterprises.com wrote:
On Tue, Mar 24, 2009 at 4:30 AM, Hrvoje Niksic hrvoje.nik...@avl.comwrote:
Agreed, and more importantly, I have yet to be convinced that those NULL
checks introduce a measurable slowdown. Daniel, have
2009/3/24 Daniel Stutzbach dan...@stutzbachenterprises.com:
[...]
100 nanoseconds, py3k trunk:
ceval - PyObject_GetItem (object.c) - list_subscript (listobject.c) -
PyNumber_AsSsize_t (object.c) - PyLong_AsSsize_t (longobject.c)
[more timings snipped]
Does removing the PyLong_Check call in
On Tue, Mar 24, 2009 at 10:13 AM, Mark Dickinson dicki...@gmail.com wrote:
2009/3/24 Daniel Stutzbach dan...@stutzbachenterprises.com:
[...]
100 nanoseconds, py3k trunk:
ceval - PyObject_GetItem (object.c) - list_subscript (listobject.c) -
PyNumber_AsSsize_t (object.c) - PyLong_AsSsize_t
On Tue, Mar 24, 2009 at 3:50 PM, Daniel Stutzbach
dan...@stutzbachenterprises.com wrote:
On Tue, Mar 24, 2009 at 10:13 AM, Mark Dickinson dicki...@gmail.com wrote:
Does removing the PyLong_Check call in PyLong_AsSsize_t
make any noticeable difference to these timings?
Making no other changes
Mark Dickinson dickinsm at gmail.com writes:
Making no other changes from the trunk, removing the PyLong_Check and NULL
check from PyLong_AsSsize_t shaves off 4 nanoseconds (or around 4% since the
trunk is around 100 nanoseconds).
Thanks. I'd call that a noticeable difference.
4% on a
2009/3/24 Daniel Stutzbach dan...@stutzbachenterprises.com:
On Tue, Mar 24, 2009 at 10:13 AM, Mark Dickinson dicki...@gmail.com wrote:
2009/3/24 Daniel Stutzbach dan...@stutzbachenterprises.com:
[...]
100 nanoseconds, py3k trunk:
ceval - PyObject_GetItem (object.c) - list_subscript
4% on a micro-micro-benchmark is hardly compelling...
I concur! This is utterly insignificant and certainly does
not warrant removing the checks.
-1 on these sort of fake optimizations. We should focus
on algorithmic improvements and eliminating redundant
work and whatnot. Removing checks
On 24-Mar-09, at 3:15 PM, Raymond Hettinger wrote:
4% on a micro-micro-benchmark is hardly compelling...
I concur! This is utterly insignificant and certainly does
not warrant removing the checks.
-1 on these sort of fake optimizations. We should focus
on algorithmic improvements and
4% on a micro-micro-benchmark is hardly compelling...
I concur! This is utterly insignificant and certainly does
not warrant removing the checks.
-1 on these sort of fake optimizations. We should focus
on algorithmic improvements and eliminating redundant
work and whatnot. Removing checks
In Python 2.5, list objects were special-cased to skip PyObject_GetItem and
go straight to PyList_GET_ITEM. That special case gave made other sequences
20% slower than lists for getitem operations. The special case was removed
in Python 3 (haven't checked 2.6).
Today I was tracing through how
Daniel Stutzbach wrote:
1) Assume the index is a PyLong until proven otherwise
The PyIndex_Check in PyObject_GetItem looks pretty useless. If it
returns false, PyObject_GetItem throws a type error. If we skipped the
PyIndex_Check when it would have returned false, PyNumber_AsSsize_t
would
Nick Coghlan wrote:
The main problem is that many of these methods are not only used
internally, but are *also* part of the public C API made available to
extension modules. We want misuse of the latter to trigger exceptions,
not segfault the interpreter.
But is it worth slowing everything
17 matches
Mail list logo
