islice vs list Slice Windows: Localhost Lab

Intro — what this post promises

Take a window from a large sequence via itertools.islice vs list[start:stop] (plus next(islice) vs index). This lab reports ops/s on Linux localhost.

It is not the itertools micro-loop bake-off (lab 55) and not chain/flatten (lab 67). Focus: windowing / skipping.

Related links:

• 01shoppercove.comitertools vs python loops localhost lab
• 02shoppercove.comitertools chain vs flatten localhost lab
• 03shoppercove.comheapq merge vs sorted localhost lab
• 04shoppercove.comzlib vs gzip compress localhost lab
• 05shoppercove.comdifflib vs set ops localhost lab
• 06shoppercove.comconfigparser vs json localhost lab
• 07shoppercove.comhtml escape vs manual localhost lab
• 08shoppercove.commethodcaller vs getattr localhost lab

Lab honesty (1 Oct 2026 IST): Python 3.13.5. Affiliates: 0. Source list length 200000.

Verdict up front: head 100 — list[:100] ~7162375 ops/s vs islice→list ~1217428; mid 100 @ 50k — list slice ~4267167 vs islice ~7607 (skip tax!). Streaming first-100 from count: islice ~1140818 vs materialize-200k-then-slice ~263.

Arms

Lab topology

n=200_000 list · windows head/mid/tail · batched inner loops · 7 rounds · p50
metric: ops/s = inner / p50_s

Script: lab-evidence/109-islice-vs-list-slice/results/run_lab.py.

Lead table — head vs mid (width 100)

List slice is O(width). islice on a list still walks/skips to start — catastrophic for mid/tail windows.

Mid 10k & single-element

Streaming win

islice is the right tool for “first N of a stream.” Never build a giant list just to slice the head.

API rule of thumb

islice(iterable, start, stop) always advances the underlying iterator. Sequences implement efficient __getitem__ slices — use them. Reach for islice when you only have an iterable protocol (files, generators, network cursors).

Reading it

• Have a list and a random window → list[start:stop].
• Have an iterator / infinite stream → islice.
• Avoid islice to skip far into a list — use indexing/slicing.
• next(islice(seq, i, i+1)) is not a substitute for seq[i] on sequences.

Skip cost intuition

islice(seq, start, stop) must consume start items even when seq is a list — it uses the iterator protocol, not __getitem__ ranges. That is why mid/tail windows collapse from millions of ops/s (slice) to thousands (islice) on this box. The API is correct; the access pattern is wrong for random-access sequences.

Files and cursors

For line iterators, DB cursors, and network streams, list slicing is unavailable until you buffer. There islice (or a bounded for-loop with a counter) is the natural “page” tool — exactly where the streaming arm of this lab applies.

Pitfalls

• Using islice for mid-list windows on concrete lists.
• Materializing huge ranges to take a head slice.
• Confusing with chain/loop labs (55/67).
• Assuming islice is “always lazier/faster” on lists.

Reproduce

python3 lab-evidence/109-islice-vs-list-slice/results/run_lab.py

Evidence: summary.json, summary.txt.

Prefer documenting why a window is taken (UI page, batch boundary, probe sample) so future readers do not “optimize” a streaming islice back into an accidental full materialization.

Limits

One Linux box. Random-access list + synthetic generators. Not memory-mapped file windows.

Takeaway

On lists, slice wins (head ~7162375 ops/s vs islice ~1217428; mid islice drops to ~7607). On streams, islice crushes materialize-then-slice (~1140818 vs ~263 ops/s).