What does slicing a string cost?

A slice is a copy, never a view. s[2:6] allocates a new string and copies four characters, so slicing is O(k) in both time and memory for a slice of length k. One slice is free; a slice per iteration is how an O(n) scan quietly becomes O(n²).

Overview

Copy, not view

Some languages hand you a slice that points into the original buffer, so taking one is O(1). Python does not: s[2:6] allocates a new string object and memcpys four characters into it. The cost is proportional to the slice, not to the original.

You can prove it from the interpreter: the id differs, and mutating is impossible anyway, so there is no aliasing to observe. What you can measure is the time, which is what the editor below does.

StringsConceptualEasy

Step through it

What to watch

  • The second row is a separate object, not a window into the first.
  • s[::-1] copies the whole string — fine once, expensive in a loop.
  • Compare with memoryview, which really is a view — but only over bytes.

Say this out loud

"Slices copy. It's O(k) time and space for a k-length slice, so inside a loop I carry indices instead of slicing."

What does slicing a string cost?

What does s[2:6] cost, and is it a view or a copy?

Where it actually hurts

One slice costs nothing worth thinking about. The problem is the shape where a slice is taken per iteration — checking every substring, or peeling a character off the front:

while s: first, s = s[0], s[1:]

Each iteration copies the entire remainder, so an O(n) walk becomes O(n²). The same bug appears in recursive solutions that pass s[1:] down: correct, elegant, and quadratic.

What to do instead

Carry indices. Every algorithm on this track that scans text — two pointers, sliding window, KMP — keeps i and j into the original string and never slices inside the loop. Slice once at the end, when you need the answer as a string.

If you genuinely need a zero-copy view over a large buffer, that exists, but only for bytes: memoryview(b) slices in O(1) and shares the underlying memory.

Run it in Python

The same scan written twice — once slicing on every iteration, once carrying indices — timed at three sizes so the quadratic separates from the linear in front of you.

slicing.pyPython 3
Output

How the code works

  1. part is sFalse. The slice is a separate object holding its own four characters, which is the entire question.
  2. text = text[1:]Looks like advancing a pointer and is nothing of the sort: it allocates a string one shorter and copies into it. Doing that n times copies about n²/2 characters.
  3. i += 1The same traversal with no allocation at all. This is why every scanning algorithm here carries indices rather than slicing.
  4. memoryview(b"algorithms")The zero-copy answer, and the reason to know the difference: slicing a memoryview is O(1) and shares memory. It works on bytes, not str.

Change one thing

  • Write the recursive version — def walk(s): return 1 + walk(s[1:]) if s else 0. Elegant, and quadratic for the same reason.
  • Raise n to 40,000 and watch the ratio roughly double again.

Where this runs

Real CPython, compiled to WebAssembly and running on your own machine — nothing is uploaded. The first run takes a few seconds while the interpreter downloads; after that it is immediate. Need more room, or want to paste your own attempt? Use the Python compiler.

Check yourself

0 of 3

Answer without scrolling back up.

  1. s[2:6] returns:

  2. Why does peeling characters off the front with s = s[1:] go quadratic?

  3. Which type gives you a genuine zero-copy slice?

Cheat sheet

What does slicing a string cost?

A slice is a copy, never a view. s[2:6] allocates a new string and copies four characters, so slicing is O(k) in both time and memory for a slice of length k. One slice is free; a slice per iteration is how an O(n) scan quietly becomes O(n²).

INTERVIEW · vizlearn.in/interview/what-does-string-slicing-cost.html

About the author

Ashish Jangra builds and maintains VizLearn. Every module here is written and the visualisation behind it hand-built, so the numbers in a readout come from the same code that draws the picture. Corrections are genuinely welcome and get priority over everything else — if a page states something wrong, or an animation misrepresents what the algorithm does, get in touch.