[issue18813] Speed up slice object processing

[Stefan Behnel]

Stefan Behnel added the comment:

Closing as not worth doing.

--
resolution:  -> rejected
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18813] Speed up slice object processing

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

So may be close this issue as it doesn't affect performance?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18813] Speed up slice object processing

[Stefan Behnel]

Stefan Behnel added the comment:

> why you pass through fast path only if -1<= Py_SIZE(v) <=1?

It's usually enough, it's the fastest fast path, and it doesn't even need
error handling.

Any slicing where the slice calculation time matters is going to be of
fairly limited size, often involving the values (!) 1 or -1 in the slice
object fields, but definitely small integers.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18813] Speed up slice object processing

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Indeed, PySequence_GetSlice() is used only in few performance non-critical 
places in the stdlib, PySequence_Set/DelSlice() are not used at all. So looks 
as this way doesn't speed up any code.

As for faster_PyEval_SliceIndex.patch see issue17576. May be such optimization 
is not always correct (only for exact PyLong). And why you pass through fast 
path only if -1<= Py_SIZE(v) <=1?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18813] Speed up slice object processing

[Stefan Behnel]

Stefan Behnel added the comment:

I reran the benchmarks with the fast path in _PyEval_SliceIndex() and the 
results are not conclusive. There is no clear indication that it improves the 
performance.

The problem is that most slices have no step, many slices are open ended on at 
least one side (i.e. usually have one or two fields set to None) and they are 
only used once, so integer index optimisations can only have a limited impact 
compared to instantiating the slice object in the first place.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18813] Speed up slice object processing

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

> There could be two implementations of "slice", one that
> uses Python object indices (as currently) and one that has Py_ssize_t
> indices  (and properties for the start/stop/step attributes).

Agree, this idea LGTM. Single boolean flag should be enough to switch between 
implementations. This shouldn't break well written code. The PySliceObject 
structure is not a part of stable API.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18813] Speed up slice object processing

[Stefan Behnel]

Stefan Behnel added the comment:

Thanks for the review, Serhiy. There isn't really a reason not to 'normalise' 
the Python step object to None when 1 is passed from C code, so I updated the 
patch to do that.

Regarding on-demand creation of the Python values, the problem is that C code 
that accesses the struct fields directly would not be prepared to find NULL 
values in them, so this would be a visible change and potential source of 
crashes. However, my guess is that this would rarely be a problem (see my last 
comment on changing the slice type internally).

--
Added file: http://bugs.python.org/file37205/cache_slice_indices.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18813] Speed up slice object processing

[Stefan Behnel]

Stefan Behnel added the comment:

Here's another idea. There could be two implementations of "slice", one that 
uses Python object indices (as currently) and one that has Py_ssize_t indices  
(and properties for the start/stop/step attributes). Similar to what Unicode 
strings do, the slice type would decide which to use at instantiation time.

The internals of PySliceObject are not part of the stable ABI, and the normal 
way to figure out the indices is PySlice_GetIndicesEx(), which would be adapted 
accordingly.

This breaks compatibility with some C extensions that access the slice 
attributes directly, but that should be rare, given how complex index 
calculations are.

This change is certainly more invasive than adding Py_ssize_t fields to the 
existing object, though.

--
versions: +Python 3.5 -Python 3.4

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18813] Speed up slice object processing

[Stefan Behnel]

Stefan Behnel added the comment:

As mentioned, the fannkuch benchmark benefits quite a bit from the fast path, 
by 8%. It was a while ago when I tested, though, so I don't have exact numbers 
ATM.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18813] Speed up slice object processing

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Are there any benchmarks?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18813] Speed up slice object processing

[Stefan Behnel]

Changes by Stefan Behnel :


Removed file: http://bugs.python.org/file31421/faster_PyEval_SliceIndex.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18813] Speed up slice object processing

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
nosy: +mark.dickinson, serhiy.storchaka
stage:  -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18813] Speed up slice object processing

[Stefan Behnel]

Stefan Behnel added the comment:

Here is another patch that remembers the Py_ssize_t slice indices if they are 
known at instantiation time. It only makes a very small difference for the 
"fannkuch" benchmark, so that's no reason to add both the complexity and the 
(IMHO ignorable) memory overhead.

However, it also adds a public C-API function PySlice_FromIndices() that allows 
setting the values from C code at instantiation time, thus avoiding the 
overhead of having to do the conversion back again.

It might also be worth exploring if we can't instantiate the Python object 
indices at first request using properties, iff the slice was created with 
integer indices. Meaning, we'd leave the PyObject* fields NULL in that case 
until they are being used. That would reduce the overhead of creating the slice 
object in the first place. Since we added the one-instance cache, it's now 
dominated by the creation of the index value objects when 
_PySlice_FromIndices() is being used internally (e.g. when calling 
PySequence_Get/Set/DelSlice()).

--
Added file: http://bugs.python.org/file31431/cache_slice_indices.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18813] Speed up slice object processing

[Stefan Behnel]

Stefan Behnel added the comment:

And in fact, callgrind shows an *increase* in the number of instructions 
executed for the "use locals" patch (898M with vs. 846M without that patch when 
running the fannkuch benchmark twice). That speaks against making that change, 
I guess.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18813] Speed up slice object processing

[Stefan Behnel]

Stefan Behnel added the comment:

Another patch, originally proposed in issue10227 by Kristján Valur Jónsson. It 
uses local variables instead of pointers in PySlice_GetIndicesEx(). I see no 
performance difference whatsoever (Linux/gcc 4.7), but also I can't see a 
reason not to do this. I think it cleans up the code a bit.

--
Added file: 
http://bugs.python.org/file31423/use_locals_in_PySlice_GetIndicesEx.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18813] Speed up slice object processing

[Stefan Behnel]

Stefan Behnel added the comment:

Sorry, broken patch. Here's a new one (same results).

--
Added file: http://bugs.python.org/file31422/faster_PyEval_SliceIndex.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18813] Speed up slice object processing

[Stefan Behnel]

Stefan Behnel added the comment:

This tiny patch adds a fast-path to _PyEval_SliceIndex() that speeds up the 
slicing-heavy "fannkuch" benchmark by 8% for me.

--
keywords: +patch
Added file: http://bugs.python.org/file31421/faster_PyEval_SliceIndex.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18813] Speed up slice object processing

[Stefan Behnel]

New submission from Stefan Behnel:

The get/set/delitem slicing protocol has replaced the old Py2.x 
get/set/delslice protocol in Py3.x. This change introduces a substantial 
overhead due to processing indices as Python objects rather than plain 
Py_ssize_t values. This overhead should be reduced as much as possible.

This ticket can be seen as a more general follow-up to issue10227.

--
components: Interpreter Core
messages: 195918
nosy: pitrou, scoder
priority: normal
severity: normal
status: open
title: Speed up slice object processing
type: performance
versions: Python 3.4

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com