Python Memoryview Performance: Zero-Copy Data Access

What Is a Memoryview?

A memoryview is a built-in Python type that exposes an object's internal buffer without copying the underlying data. It lets you read and write the same memory that the original object owns, using a different interface. For performance-sensitive code, this avoids the allocation and copy overhead that comes from converting large binary data to bytes or bytearray repeatedly.

The primary reason to care about python memoryview performance is that slicing a memoryview returns another memoryview that references the same buffer, not a copy. This is fundamentally different from slicing a bytes object, which creates a new bytes object and copies the selected range.

data = b"0123456789"
view = memoryview(data)
sub = view[2:5]
print(sub.tobytes())  # b'234'
print(view.obj is data)  # True

The view.obj attribute holds the original object, and sub still references that same buffer. No bytes were copied when creating sub.

How Memoryview Uses the Buffer Protocol

The buffer protocol is the internal contract that allows objects like bytes, bytearray, and array.array to expose their raw memory to other objects. A memoryview is a consumer of that protocol. It does not own the data; it references it.

When you create a memoryview from a supported object, Python records the object's memory layout, including its shape, stride, and format. This metadata is what allows memoryview to interpret the raw bytes correctly when you access elements or slice the view.

import array
arr = array.array('H', [1, 2, 3, 4])
view = memoryview(arr)
print(view.format)  # 'H' for unsigned short
print(view.itemsize)  # 2 bytes per element
print(view.shape)  # (4,)

The format attribute describes the type of each element, and itemsize tells you how many bytes each element occupies. This matters for performance because you can avoid converting data to Python objects when you only need to read raw bytes.

Where Memoryview Improves Performance

The most direct performance benefit appears when you repeatedly access or slice large binary data. Consider a protocol parser that reads a header and then a payload from a network buffer. If you convert the buffer to bytes and slice it, each slice copies data. With memoryview, you can slice without copying, and you can even pass the view directly to functions that accept buffer-like objects.

def parse_frame(frame: memoryview):
    header = frame[:8]
    payload = frame[8:]
    # header and payload are views, not copies
    return header, payload

The same pattern with bytes would allocate two new bytes objects. For a stream of many frames, those allocations add up. Using memoryview keeps the original buffer intact and only creates lightweight view objects.

Another common case is reading from a file. When you read a large chunk, you can wrap it in a memoryview and slice it into records without duplicating the chunk in memory.

with open("data.bin", "rb") as f:
    chunk = f.read(1024 * 1024)
    view = memoryview(chunk)
    # process records without copying
    for offset in range(0, len(view), 16):
        record = view[offset:offset + 16]

This reduces memory pressure and allocation overhead, which is especially valuable when processing multi-megabyte files.

Comparing Memoryview with Bytes and Bytearray

The choice between memoryview, bytes, and bytearray depends on whether you need mutability and whether you can tolerate copies.

If you need to modify the underlying data, bytearray is a natural choice, but slicing it still copies. A memoryview of a bytearray allows you to modify the original buffer through the view, and slicing a memoryview of a bytearray gives you a writable view without copying.

buf = bytearray(b"abcdef")
view = memoryview(buf)
view[1:4] = b"XYZ"
print(buf)  # bytearray(b'aXYZef')

This is a powerful way to update parts of a buffer in place, which can be much faster than creating new bytearray objects for each modification.

Practical Patterns for High-Volume Data

For high-volume data processing, the key is to keep the original buffer alive as long as the views are in use. If you create a memoryview from a temporary bytes object and that object goes out of scope, the view still holds a reference to it, so the data remains valid. This is useful when you want to pass a slice of a large buffer to a function without copying.

def process(data: bytes):
    view = memoryview(data)
    # keep view alive while processing
    return view[::2]  # even-indexed bytes as a view

Another pattern is using memoryview.cast to reinterpret the buffer as a different type. This can avoid manual unpacking and repacking of binary data.

data = b"\x01\x02\x03\x04"
view = memoryview(data)
ints = view.cast('I')  # reinterpret as unsigned ints
print(ints[0])  # 0x04030201 on little-endian systems

Casting does not copy the data; it only changes the interpretation. This can be much faster than using struct.unpack in a loop, especially for large arrays.

Pitfalls That Undermine Performance

A memoryview is not a performance silver bullet. If you call tobytes() on a view, you force a copy. The same happens when you use bytes(view) or pass the view to a function that expects a contiguous bytes object. Any operation that materializes the data into a new object eliminates the zero-copy benefit.

Another subtle issue is that memoryview can be slower than direct bytes access for very small data. The overhead of creating a view and accessing its attributes may outweigh the copy cost for tiny slices. The benefit becomes clear only when the data size is large enough that copying is measurable.

Also, not all objects support the buffer protocol. Custom classes need to implement it to be used with memoryview. For most built-in types like bytes, bytearray, and array.array, it works out of the box.

Finally, be careful with the lifetime of the original object. If you create a memoryview from a temporary object that is immediately garbage-collected, the view still holds a reference, so it's safe. But if you release the view and then try to access the data, you'll get an error. The view must be kept alive as long as you need the data.

Measuring the Actual Performance Gain

To know whether memoryview helps in your specific case, measure it. Use timeit or a profiler to compare the same operation with and without memoryview. The gain is not automatic; it depends on how often you would otherwise copy data and how large the data is.

A simple comparison for slicing a large bytes object:

import timeit

data = b"x" * 10_000_000

def slice_bytes():
    for _ in range(1000):
        sub = data[1000:9000]

def slice_view():
    view = memoryview(data)
    for _ in range(1000):
        sub = view[1000:9000]

print(timeit.timeit(slice_bytes, number=1))
print(timeit.timeit(slice_view, number=1))

The slice_view function should complete faster because it does not allocate a new 8000-byte object on each iteration. The actual difference depends on your hardware and Python version, but the mechanism is clear: fewer allocations and fewer memory copies.

When you measure, also consider the memory footprint. Using memoryview can reduce peak memory usage because you avoid creating multiple copies of large data. This is often more important than raw speed in memory-constrained environments.