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 eli
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
2009/3/24 Daniel Stutzbach :
> On Tue, Mar 24, 2009 at 10:13 AM, Mark Dickinson wrote:
>>
>> 2009/3/24 Daniel Stutzbach :
>> > [...]
>> > 100 nanoseconds, py3k trunk:
>> > ceval -> PyObject_GetItem (object.c) -> list_subscript (listobject.c) ->
>> > PyNumber_AsSsize_t (object.c) -> PyLong_AsSsize_
Mark Dickinson 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 m
On Tue, Mar 24, 2009 at 3:50 PM, Daniel Stutzbach
wrote:
> On Tue, Mar 24, 2009 at 10:13 AM, Mark Dickinson wrote:
>> Does removing the PyLong_Check call in PyLong_AsSsize_t
>> make any noticeable difference to these timings?
>
> Making no other changes from the trunk, removing the PyLong_Check a
On Tue, Mar 24, 2009 at 10:13 AM, Mark Dickinson wrote:
> 2009/3/24 Daniel Stutzbach :
> > [...]
> > 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 sni
2009/3/24 Daniel Stutzbach :
> [...]
> 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 PyLong_AsSsize_t
make an
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 wrote:
>
>> Agreed, and more importantly, I have yet to be convinced that those NULL
>> checks introduce a measurable slowdown. Daniel, have you tried measu
On Tue, Mar 24, 2009 at 4:30 AM, Hrvoje Niksic wrote:
> 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 play around with diffe
Raymond Hettinger 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.
__
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 branc
Hrvoje Niksic 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 special case
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 alr
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 dow
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
>
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 Py
17 matches
Mail list logo
