Can a PHP Cache Really Read Large Arrays Without Copying Them?

Reading a cached value should be cheap. Yet in PHP, retrieving a large array from a shared-memory cache can involve reconstructing or copying data into the requesting process. The larger the structure, the more work may be required before the application can use it.

A new open-source extension called nocopy proposes a different approach: make suitable cached data directly readable from shared memory, avoiding the usual copy on retrieval.

Developed by Christian Fritsch, nocopy is currently at version 0.0.1. Its published benchmarks report striking improvements over APCu, particularly for large arrays. But this is an early release, and its author explicitly provides no stability guarantee.

That makes nocopy an interesting candidate for PHP Projects Radar: an ambitious technical implementation that deserves examination rather than an unqualified recommendation.

The hidden cost of retrieving cached data

APCu allows PHP applications to cache values in shared memory. Multiple PHP workers can access the same cached information, but retrieving a complex value normally requires constructing a usable PHP value for the current request.

For small scalar values, this overhead may be negligible. For large arrays containing thousands of elements, the cost can become more significant, particularly when the same structure is retrieved repeatedly.

nocopy attempts to avoid this work by allowing PHP to reference an appropriate shared-memory representation directly.

Conceptually, instead of reconstructing a thousand-element array on every read, the extension exposes a representation already present in shared memory.

This is not simply a userland caching wrapper. nocopy is a native extension implemented in C and interacts with PHP’s runtime and memory-management mechanisms.

The performance claims

The project’s README reports approximately 12 nanoseconds for reading a cached 1,000-row array, compared with approximately 200 microseconds using APCu in the author’s benchmark.

It also reports substantial throughput improvements in selected Symfony and Drupal workloads.

These figures should be interpreted carefully. They are measurements published by the project, not independently reproduced by PHP Magazine. They describe particular hardware, software versions, workloads, and benchmark configurations.

The repository identifies Linux and Docker on an Apple M3 Pro using PHP 8.5 among its test environments. It also discusses testing on AWS Graviton4.

More importantly, the author acknowledges that not every reported application-level improvement comes from zero-copy reads. In the Drupal integration, moving cache bins and tags away from database-backed storage accounts for much of the benefit.

That distinction matters. Comparing two complete application configurations does not isolate the performance contribution of one low-level optimization.

What happens when the application modifies a value?

Sharing data efficiently creates an immediate correctness question: what happens if one PHP request changes an array that another request is reading?

According to the project’s documentation, nocopy relies on copy-on-write behavior. A retrieved value can be read from shared memory, while modifications cause PHP to work with a private representation rather than changing the shared value unexpectedly.

This behavior is central to the extension’s design. A shared cache must not allow one request to silently modify another request’s data.

However, correctness deserves as much scrutiny as speed. Nested structures, reference handling, object reconstruction, and long-running workers create additional cases that should be tested before production adoption.

The project notes that most objects are reconstructed from their stored properties rather than being returned as the same shared object. Consequently, the zero-copy description should not be interpreted as a universal guarantee for every PHP value type.

A shared cache for PHP-FPM and CLI

One of nocopy’s more interesting architectural features is its shared cache across PHP execution contexts on the same machine.

The project describes support for PHP-FPM workers, command-line scripts, scheduled jobs, and frameworks using long-running worker modes.

It also claims that the cache can survive PHP-FPM restarts. This could be useful for applications whose operational tools and web processes need access to the same cached information.

Long-running processes require additional care because they may retain references across multiple operations. The documentation describes a safer mode for such workers that uses private copies and reuses them while the shared entry remains unchanged.

Cache stampedes and eviction

Beyond zero-copy reads, nocopy provides functionality for coordinating expensive cache population.

Its nocopy_remember() function is designed to avoid multiple workers computing the same missing value simultaneously. The project also describes refresh behavior intended to reduce sudden cache-expiration pressure.

For memory management, nocopy implements an eviction strategy that aims to retain frequently accessed entries instead of discarding the entire cache when capacity is exhausted.

These capabilities are relevant, but they should be evaluated independently. A cache may perform exceptionally well for reads while still requiring careful examination of write contention, eviction behavior, crash recovery, and operational observability.

Trying nocopy

The repository provides a Docker-based development environment. Its README documents the following initial experiment:

git clone https://github.com/chrfritsch/nocopy
cd nocopy

./dev shell

php -r 'nocopy_put("a", [1, 2, 3]); var_dump(nocopy_get("a"));'

For a server installation, the project documents installation through PIE:

pie install chrfritsch/nocopy

The documented server requirements include Linux, PHP 8.4 or later, PHP development tools, and a C compiler.

A minimal configuration also requires a shared-memory name and size, for example:

nocopy.shm_name=/nocopy
nocopy.shm_size=128M

These commands are taken from the project’s documentation. PHP Magazine has not independently built or executed the extension as part of this review.

Framework integration and multi-server operation

The repository includes integrations for Symfony and Drupal, along with an APCu-compatible function layer intended to simplify migration for selected applications.

The author also documents a Valkey-backed configuration for synchronization across multiple servers, while maintaining local caches for fast reads.

This introduces a different set of architectural questions: synchronization latency, consistency during network interruptions, invalidation behavior, and the operational cost of maintaining multiple cache tiers.

The project documentation describes these capabilities, but teams should verify the relevant guarantees against their own failure scenarios before relying on them.

The production-readiness question

nocopy is currently a first release with no stability promise. That is a significant qualification for an extension operating close to PHP’s memory-management internals.

Native extensions require compatibility testing with the precise PHP runtime, build configuration, and execution model in use. This is particularly relevant during a new PHP release cycle when extension APIs or ABIs may change.

Before adopting nocopy, teams should reproduce representative benchmarks, run the project’s tests, examine supported data types, evaluate failure recovery, and confirm the behavior of their framework integration.

A useful evaluation would compare identical application workloads with APCu and nocopy while keeping the rest of the architecture unchanged. It should measure not only throughput but also memory consumption, latency distribution, write performance, and operational stability.

An ambitious experiment worth following

nocopy explores a meaningful performance limitation: the cost of repeatedly reconstructing complex cached data for individual PHP requests.

Its proposed solution is technically ambitious, and its published results justify further investigation. But an impressive microbenchmark is not equivalent to production readiness.

For now, nocopy is best viewed as an experimental extension worth testing in controlled environments, especially for cache-heavy workloads involving large, frequently read arrays.

The most interesting question is not whether one benchmark shows an enormous speedup. It is whether the design can deliver measurable application-level improvements while preserving the correctness, compatibility, and reliability expected of a production PHP cache.