[issue18813] Speed up slice object processing

Stefan Behnel added the comment: Closing as not worth doing. -- resolution: -> rejected status: open -> closed ___ Python tracker ___ ___

[issue18813] Speed up slice object processing

Serhiy Storchaka added the comment: So may be close this issue as it doesn't affect performance? -- ___ Python tracker ___ ___ Python-

[issue18813] Speed up slice object processing

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 th

[issue18813] Speed up slice object processing

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

[issue18813] Speed up slice object processing

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 (

[issue18813] Speed up slice object processing

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 swi

[issue18813] Speed up slice object processing

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 acc

[issue18813] Speed up slice object processing

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 w

[issue18813] Speed up slice object processing

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

[issue18813] Speed up slice object processing

Serhiy Storchaka added the comment: Are there any benchmarks? -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue18813] Speed up slice object processing

Changes by Stefan Behnel : Removed file: http://bugs.python.org/file31421/faster_PyEval_SliceIndex.patch ___ Python tracker ___ ___ Python-bug

[issue18813] Speed up slice object processing

Changes by Serhiy Storchaka : -- nosy: +mark.dickinson, serhiy.storchaka stage: -> patch review ___ Python tracker ___ ___ Python-bug

[issue18813] Speed up slice object processing

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 overhea

[issue18813] Speed up slice object processing

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. -- ___

[issue18813] Speed up slice object processing

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

[issue18813] Speed up slice object processing

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 _

[issue18813] Speed up slice object processing

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

[issue18813] Speed up slice object processing

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