If you look at the implementation of deque.rotate(), it does the equivalent of deque.append(deque.popleft()) or deque.appendleft(deque.pop()).

Unfortunately, for larger rotations, the pop() and append() calls just do too much work. Since the documentation recommends using rotate() to do slicing-style operations, this could get seriously slow.

deque.rotate() could just touch up the internal pointers and use memmove() to realign the data.

Benchmarks, of course, would have to be written to make sure this is a win.

The easiest change would essentially involve inlining the code for append/appendleft and then removing unneeded steps (the state update, the INCREF/DECREF of item, and the TRIM() test).  

Of these, the INCREF/DECREF is likely to be a nice win because we can rotate without visiting all the underlying objects (each of which would likely be a cache-line miss).

Looking at the implementation (rather quickly)[1]. I'm wondering if there is a reason why the appendleft(pop()) loop is required. It would seem the best way would be to determine the new head link, make the previous link the new end link and concatenate the two chains (by just swapping some pointers).
        

[1]. http://hg.python.org/cpython/file/a4292889e942/Modules/_collectionsmodule.c#l429

New changeset 9fb793b60e79 by Raymond Hettinger in branch 'default':
Issue #16398: Optimize deque.rotate()
http://hg.python.org/cpython/rev/9fb793b60e79

John, that wouldn't work because the blocks are fixed length and the endmost blocks are typically only partially filled, so all the data elements have to shift positions within their blocks.

New changeset 0d81333bde78 by Raymond Hettinger in branch '2.7':
Issue #16398: Optimize deque.rotate()
http://hg.python.org/cpython/rev/0d81333bde78

I am OK with this patch being applied to 2.7, but I wonder why. This is not a bugfix... :-)

Why only 2.7 and 3.4?

Jesús, I backported this to 2.7 because it was affecting intended usability of multiple parts of the API.  The current code had the egregious and unintended side-effect of touching every data element during a rotate -- this resulted in a huge number of unnecessary cache line misses and was blowing useful data out of cache.

IMO, a performance bug is different from a micro-optimization, especially if it is affecting the intended uses for part of an API.

Serhiy, you're welcome to backport to 3.3 if you desire.

New changeset f7b01daffe01 by Raymond Hettinger in branch 'default':
Issue 16398: Use memcpy() in deque.rotate().
http://hg.python.org/cpython/rev/f7b01daffe01

New changeset cb5cde9e5ac5 by Raymond Hettinger in branch '2.7':
Issue 16398: Use memcpy() in deque.rotate().
http://hg.python.org/cpython/rev/cb5cde9e5ac5

Raymond, looking at your patch, can we assert that deque->leftblock is never equal to deque->rightblock? If not, you need to use memmove() instead of memcpy(), which is unsafe for overlapping arrays.

It is not clear to me that this invariant is true. At the very least, an assertion should be there to protect future refactorings.

Even when leftblock == rightblock, a memcpy() will work fine.  When the block extends off the end, it *always* creates a newblock and never wraps around to the current block.  Data doesn't get overwritten in any scenario.

Also note, len>=1 and |n| < len//2, so even within a single block, memcpy() doesn't overwrite data.

It is possible to use only one new block (or even none). It should a little speed up rotate(). I will open a new issue when prepare a patch.

New changeset efb8d80af320 by Raymond Hettinger in branch 'default':
Issue 16398:  Add assertions to show why memcmp is safe.
http://hg.python.org/cpython/rev/efb8d80af320

New changeset 12ef5a4bba63 by Raymond Hettinger in branch 'default':
Issue 16398: One more assertion for good measure.
http://hg.python.org/cpython/rev/12ef5a4bba63