DEV Community: Alex

The Background-Tab Bug I Missed in My JavaScript Polling Code

Alex — Thu, 20 Aug 2026 10:50:13 +0000

I thought replacing setInterval() with recursive setTimeout() had made a polling loop safe. Only one request would run at a time, and I cleared the next timeout when the page became hidden.

It still had a race.

The timeout was gone. The request already in flight was not.

If the page became visible again before that old request finished, a new polling run could start. The old response could then arrive last and overwrite fresher state. Nothing in clearTimeout() protected the UI from it.

That was more dangerous than the timer drift I had started investigating. A late counter is visible. A stale response can look completely normal.

Fixing it required three separate decisions:

timestamps measure elapsed time;
visibility changes trigger a resynchronisation;
cancellation and a run identifier prevent stale requests from updating state.

The browser is allowed to delay background work. The application still has to know which work is current.

First, prove that a timer is not a clock

Before changing the polling code, I wanted a small test that separated elapsed time from callbacks. It asks for an interval callback every second and displays four values:

elapsed wall time;
callbacks actually delivered;
the difference between those two counters;
the largest gap between callbacks.

I am deliberately not publishing one “background tabs delay callbacks by exactly N seconds” result. The policy depends on the browser, version, operating system, power state, audio, WebRTC, and resource pressure. A number from one machine would be easy to repeat and easy to misuse.

This is the smallest useful version of the test. Save it as timer-test.html and open it in a normal browser tab:

<!doctype html>
<html lang="en">
  <meta charset="utf-8" />
  <title>Background timer test</title>

  <button id="start">Start</button>
  <pre id="output">Press Start</pre>

  <script>
    const output = document.querySelector("#output");
    const startButton = document.querySelector("#start");

    let intervalId;
    let startedAt = 0;
    let lastCallbackAt = 0;
    let callbacks = 0;
    let largestGapMs = 0;

    function render() {
      const elapsedSeconds = Math.floor((Date.now() - startedAt) / 1000);
      const callbackLag = Math.max(0, elapsedSeconds - callbacks);

      output.textContent = [
        `visibility: ${document.visibilityState}`,
        `wall time: ${elapsedSeconds}s`,
        `callbacks: ${callbacks}`,
        `counter lag: ${callbackLag}s`,
        `largest callback gap: ${(largestGapMs / 1000).toFixed(2)}s`,
      ].join("\n");
    }

    startButton.addEventListener("click", () => {
      clearInterval(intervalId);

      startedAt = Date.now();
      lastCallbackAt = startedAt;
      callbacks = 0;
      largestGapMs = 0;
      render();

      intervalId = setInterval(() => {
        const now = Date.now();
        largestGapMs = Math.max(largestGapMs, now - lastCallbackAt);
        lastCallbackAt = now;
        callbacks += 1;
        render();
      }, 1000);
    });

    document.addEventListener("visibilitychange", () => {
      if (startedAt) render();
    });
  </script>
</html>

Start it, keep the page visible for a few seconds, switch to another tab for several minutes, then return and wait for the next callback. Compare wall time with the callback count and largest gap.

Do not expect one universal number. If the counters barely diverge, that is still a valid result for that browser and that run. Record the browser version, hidden duration, power state, and whether the page was playing audio before comparing it with somebody else’s result.

An interval is a request, not a clock

This counter looks harmless:

let secondsSinceUpdate = 0;

setInterval(() => {
  secondsSinceUpdate += 1;
  renderLastUpdated(secondsSinceUpdate);
}, 1000);

It does not measure time. It counts callbacks.

setInterval(callback, 1000) asks the browser not to run the callback before the delay has passed. It does not guarantee that the main thread will be available at that moment, or that a hidden page will keep receiving callbacks on the same schedule.

Browsers have good reasons for this. Background pages consume CPU and battery without producing anything the user can see. Chrome documents several levels of timer throttling, including more aggressive treatment of chained timers after a page has been hidden for a while. The exact conditions include visibility, recent audio, WebRTC use, the timer chain, and how long the page has been hidden.

That policy can change. Application correctness should not depend on reproducing one exact delay.

For a “last updated” label, the reliable source is the timestamp of the update:

const updatedAt = Date.now();

function renderAge() {
  const elapsedMs = Date.now() - updatedAt;
  renderLastUpdated(Math.floor(elapsedMs / 1000));
}

setInterval(renderAge, 1000);

The interval still decides when the display gets another chance to repaint. It no longer decides how much time passed. When the callback finally runs, the value catches up immediately.

Date.now() is wall-clock time and can move if the system clock changes. That is appropriate when comparing an event timestamp with the current clock. For measuring a duration inside one active session, use the monotonic performance.now() instead.

Give the page a return path

The Page Visibility API exposes the transition we care about:

document.addEventListener("visibilitychange", () => {
  if (document.hidden) {
    pauseNonEssentialWork();
    return;
  }

  refreshVisibleState();
});

I do not use this event to fight throttling. I use it to make returning predictable.

When the page becomes visible again, it should:

derive displayed time from timestamps;
fetch data that may have changed;
check whether real-time connections are still useful;
render from current state instead of replaying missed visual steps.

A background page is allowed to become stale. The bug is returning without noticing.

The race I nearly missed

After fixing the visible counter, I returned to the polling loop. Replacing setInterval() with recursive setTimeout() prevented overlapping schedules, and clearing the timeout prevented the next request. It still did not cancel the request already in flight.

There is an awkward sequence hidden inside that simpler code:

a request starts;
the page becomes hidden;
polling is stopped, but the request continues;
the page becomes visible and starts a new request;
the old response arrives last and overwrites the newer state.

So the controller needs both cancellation and a run identifier:

let timerId;
let activeRequest;
let runId = 0;
let running = false;

async function poll(currentRun) {
  if (!running || document.hidden || currentRun !== runId) return;

  const request = new AbortController();
  activeRequest = request;

  try {
    const response = await fetch("/api/status", {
      signal: request.signal,
    });

    if (!response.ok) {
      throw new Error(`Status request failed: ${response.status}`);
    }

    const status = await response.json();

    if (running && currentRun === runId && !request.signal.aborted) {
      updateStatus(status);
    }
  } catch (error) {
    if (error?.name !== "AbortError" && currentRun === runId) {
      reportPollingError(error);
    }
  } finally {
    if (activeRequest === request) {
      activeRequest = undefined;
    }

    if (running && currentRun === runId && !document.hidden) {
      timerId = setTimeout(() => poll(currentRun), 5000);
    }
  }
}

function startPolling() {
  stopPolling();
  running = true;
  const currentRun = ++runId;
  void poll(currentRun); // refresh immediately
}

function stopPolling() {
  running = false;
  runId += 1;
  clearTimeout(timerId);
  activeRequest?.abort();
  activeRequest = undefined;
}

document.addEventListener("visibilitychange", () => {
  document.hidden ? stopPolling() : startPolling();
});

startPolling();

This version still needs application-specific retry and backoff rules. The important properties are easier to state:

one active polling run;
one in-flight request;
stale results cannot update the page;
returning to the page triggers an immediate refresh.

In production I would test cancellation, stale-result suppression, and the hidden-page guard because this is exactly the kind of lifecycle code that looks correct until two events happen close together.

Animation frames should render state

Most browsers stop sending requestAnimationFrame() callbacks to hidden pages. That is useful: there is nothing to draw.

It becomes a problem only when frame count is also application state:

let progress = 0;

function frame() {
  progress += 0.1;
  drawProgress(progress);
  requestAnimationFrame(frame);
}

Derive the visual value from elapsed time instead:

const startedAt = performance.now();
const durationMs = 10_000;

function frame(now) {
  const progress = Math.min((now - startedAt) / durationMs, 1);
  drawProgress(progress);

  if (progress < 1) {
    requestAnimationFrame(frame);
  }
}

requestAnimationFrame(frame);

After the tab returns, the next frame renders the current position. It does not replay frames nobody saw.

For a deadline that must survive device sleep or be shared between clients, use a server timestamp or another durable wall-clock source. An animation clock and a business deadline are different jobs.

WebSockets need resynchronisation too

socket.readyState === WebSocket.OPEN tells us the browser has not marked the socket closed. It does not prove that the UI received every event while the laptop slept, the network changed, or the page was frozen.

On return I prefer this sequence:

compare the last confirmed server message with an expected freshness window;
reconnect if the connection is stale;
request events or state after the last confirmed cursor;
apply events idempotently.

Reconnecting without backfilling gives us a fresh connection to potentially incomplete state.

A Web Worker can move CPU work off the main thread, but it does not turn a browser tab into a durable process. A Service Worker is event-driven and may be terminated between events. If something must happen at a specific real-world time—billing, an email, an expiry, a scheduled job—it belongs on durable infrastructure.

What I would ship

The timer drift was expected. The stale response was the part I nearly missed.

The practical rule I now use for this failure mode is simple:

timestamps measure time;
timers request an opportunity to work;
the server owns durable truth;
visibility changes trigger resynchronisation;
cancellation prevents yesterday’s request from overwriting today’s state.

The browser is not breaking a promise when a background callback arrives late. My mistake was treating an old callback—and an old request—as if it still belonged to the current page state.

If you run the same test in Safari or Firefox, I would be interested in the browser version, hidden duration, and largest gap—not just “it drifted.” That would make the comparison useful.

PHP Profiling: What the Numbers Actually Tell Us

Alex — Sat, 16 Aug 2025 12:09:39 +0000

A profiler is most useful when it proves your first idea wrong.

I recently went back to a small PHP example that normalizes a large list of email addresses. The first version of this article had a neat story: replace array_unique(), remove repeated string operations, switch from filter_var() to a regular expression, and watch execution time fall from 12.8 seconds to 2.1 seconds.

There was one problem: the repository did not support that story.

The baseline already called trim() and strtolower() only once. The generated addresses were all unique, which made the deduplication comparison weak. The repository contained no Cachegrind output from which the quoted function percentages could be reproduced. Its peak-memory number also included the fixture built before the measured function ran.

So I rebuilt the example and measured it again. The result is less dramatic, but much more useful.

What are we trying to improve?

The example does three things:

normalize each address with trim() and strtolower();
validate it according to a declared rule;
return unique normalized strings in first-seen order.

In simplified form, the reference implementation collects accepted addresses and deduplicates them at the end:

function normalizeWithArrayUnique(array $rows, callable $validator): array
{
    $emails = [];

    foreach ($rows as $row) {
        $email = strtolower(trim($row['email']));

        if ($email !== '' && $validator($email)) {
            $emails[] = $email;
        }
    }

    return array_values(array_unique($emails, SORT_STRING));
}

The alternative uses normalized addresses as keys and therefore deduplicates while iterating:

function normalizeWithSet(array $rows, callable $validator): array
{
    $set = [];

    foreach ($rows as $row) {
        $email = strtolower(trim($row['email']));

        if ($email !== '' && $validator($email)) {
            $set[$email] = true;
        }
    }

    return array_keys($set);
}

That looks promising, but appearance is not evidence. We need a profile to find expensive work and a benchmark to determine whether a change actually helps.

Profile one case deliberately

For CLI profiling with Xdebug 3, I use a trigger instead of profiling every PHP command:

xdebug.mode=profile
xdebug.start_with_request=trigger
xdebug.output_dir=/tmp/xdebug

The output directory must exist and be writable. I can then profile one implementation:

XDEBUG_TRIGGER=1 php examples/emails/run.php baseline

Xdebug writes a cachegrind.out.* file that can be opened in a Cachegrind-compatible viewer. Self time shows work done inside a function. Inclusive time also includes its callees.

A profile is excellent for forming a hypothesis, but it is a poor place to take final wall-clock numbers. Instrumentation adds overhead, so the benchmark runs separately with Xdebug disabled:

XDEBUG_MODE=off composer bench:record

The Xdebug profiler documentation describes trigger values and output-name settings if several profiles need to be kept apart.

A fixture that exercises the code

The revised fixture is deterministic and contains 200,000 interleaved rows:

Category	Rows	Share
Unique valid addresses	100,000	50%
Duplicate valid addresses	40,000	20%
Empty values	20,000	10%
Invalid values	20,000	10%
Accepted only by the simple shape check	20,000	10%

This is still synthetic data. It does not claim to represent every import. It simply makes validation, rejection, and deduplication observable instead of filling the input with unique valid addresses only.

The last category is there for a specific reason: it exposes a behavior change that a timing table could otherwise hide.

Benchmark protocol

The runner uses one warm-up and ten measured runs for each implementation. Every sample gets a fresh PHP process, and the order of the implementations rotates between iterations.

Fixture generation happens before the timer starts. On PHP 8.2 or newer, peak accounting is reset immediately before the measured code:

$rows = EmailFixture::generate(200_000);

gc_collect_cycles();
memory_reset_peak_usage();

$baselineMemory = memory_get_usage(false);
$startedAt = hrtime(true);

$result = normalize($rows);

$elapsedSeconds = (hrtime(true) - $startedAt) / 1_000_000_000;
$peakDelta = memory_get_peak_usage(false) - $baselineMemory;

hrtime(true) is monotonic, so a system clock adjustment cannot distort the duration. Resetting the peak keeps fixture construction out of the incremental memory figure.

The runner also checks the output. The two strict implementations must have the same row count and SHA-256 checksum on every run. If they differ, the benchmark stops instead of comparing non-equivalent code.

Results

I recorded these results on PHP 8.5.9 CLI, Darwin arm64, with a 512 MiB memory limit. OPcache for CLI was off, JIT was disabled, and Xdebug was not loaded.

Implementation	Median time	Time range	Median incremental peak	Output rows
`array_unique()` + `FILTER_VALIDATE_EMAIL`	0.178650 s	0.169635–0.183735 s	24.45 MiB	100,000
Set + `FILTER_VALIDATE_EMAIL`	0.183060 s	0.178105–0.189811 s	11.60 MiB	100,000
Set + simple shape check	0.039487 s	0.037182–0.043289 s	11.60 MiB	120,000

The raw samples and environment metadata are committed in results/benchmark.json. These numbers describe this machine, PHP build, fixture, and protocol. They are not universal constants.

The recorded output is rendered directly from the committed benchmark result. The editable SVG source is stored next to the PNG in the repository.

What did the set actually improve?

Replacing array_unique() with a set reduced the median incremental peak from 24.45 MiB to 11.60 MiB. The output count and checksum matched the baseline.

It did not make this run faster. Its median was slightly higher, and the measured ranges overlap. With ten small samples, the responsible conclusion is not that the set is categorically slower. It is that this benchmark shows a clear memory improvement and no demonstrated time improvement.

That distinction matters. If memory pressure is the problem, the set is useful here. If latency is the problem, this change has not solved it.

The result may change with a different duplicate ratio, input order, PHP version, or allocator behavior. That is why the fixture and environment belong next to the numbers.

The fast regex is not the same validator

The third implementation uses:

function hasSimpleEmailShape(string $email): bool
{
    return preg_match('/^[^\s@]+@[^\s@]+\.[^\s@]+$/', $email) === 1;
}

It is much faster in this fixture, but it returns 120,000 rows rather than 100,000. It is not a drop-in optimization for FILTER_VALIDATE_EMAIL.

For example, the simple expression accepts values that PHP's validator rejects:

a..b@example.com
.alice@example.com
alice@example..com
alice@-example.com

The regex only checks for a broad something@something.something shape. That may be a valid product rule. A signup form that sends a verification message may deliberately prefer a permissive initial check. Another system may require a stricter local policy.

But that is a requirements decision, not a free performance win. A profiler can show the cost of the current validator; it cannot decide which input the application is allowed to accept. No syntax validator proves that a mailbox exists, either.

The same care applies to lowercasing the full address. It can be a reasonable application identity rule, but it should be documented as behavior rather than presented as a performance detail.

Why the original progression was misleading

One of the old steps split:

$email = strtolower(trim($row['email']));

into multiple assignments. Both forms still invoked trim() and strtolower() once for non-empty input. There was no repeated normalization to remove, so the supposed optimization did not correspond to the committed baseline.

The previous memory figures had a different problem. Calling memory_get_peak_usage() after building the entire fixture reports the highest point reached anywhere in the process. Without resetting peak accounting, that number cannot be described as the normalization function's incremental peak.

Finally, function percentages from a profiler need the corresponding profile, environment, and workload. Without that evidence, exact values such as “42% self time” look precise but cannot be checked. I removed them rather than inventing a reconstruction.

How to reproduce it

The companion repository contains the fixture, implementations, tests, runner, and recorded raw results:

github.com/phpner/php-profiling-example

composer install
composer test
XDEBUG_MODE=off composer bench

The tests verify fixture composition, first-seen order, equality of the strict implementations, and the intentional difference in the shape-check policy.

For a production import, I would investigate one more thing before micro-optimizing this loop: whether the input can be streamed. This example materializes all 200,000 rows before normalization. Reading a CSV or database cursor incrementally can remove a much larger memory cost, although the deduplication set will still grow with the number of unique addresses.

Conclusion

The corrected example does not produce a smooth sequence of wins:

the set saves incremental peak memory but does not demonstrate a speedup;
rearranging the same string calls is not an optimization;
the simple regex is faster because it implements a different acceptance policy.

That is what honest profiling often looks like. Use the profile to choose a question. Change one thing. Verify the output. Benchmark outside the profiler. If behavior changes, describe it as a tradeoff rather than hiding it behind a faster number.

Lazy Evaluation in PHP: Real‑World Memory Savings with Generators

Alex — Fri, 08 Aug 2025 16:33:47 +0000

Generators are often introduced with a neat demo: build an array with a million values, replace it with yield, and print the memory usage. The conclusion is usually correct, but the benchmark often is not.

If the array is released before memory is measured, or both implementations run in the same PHP process, the result can be misleading. I rebuilt the example around a real CSV file and ran each strategy in an isolated process.

The short version: for this workload, the eager implementation added 386.81 MiB of peak memory. The generator added 10.69 KiB. The generator was also about 13% faster in this particular test, although that part should not be treated as a general rule.

The dependable benefit of lazy iteration is bounded memory growth. Speed still depends on the work being done.

What “lazy” means here

An eager function prepares its complete result before the caller can use it:

function getNumbersArray(int $count): array
{
    $numbers = [];

    for ($number = 1; $number <= $count; $number++) {
        $numbers[] = $number;
    }

    return $numbers;
}

foreach (getNumbersArray(5) as $number) {
    echo $number . PHP_EOL;
}

By the time foreach starts, all five values already exist in the array. With five integers that is irrelevant. With a large CSV result, it can decide whether the process finishes at all.

A generator exposes the same sequence without first building the complete collection:

function getNumbersGenerator(int $count): Generator
{
    for ($number = 1; $number <= $count; $number++) {
        yield $number;
    }
}

foreach (getNumbersGenerator(5) as $number) {
    echo $number . PHP_EOL;
}

Calling getNumbersGenerator() returns a Generator object. Execution starts when iteration starts, pauses at yield, and resumes when the consumer asks for the next value.

The useful distinction is not how many values PHP can process. It is how many of them must be retained at the same time.

Streaming a CSV safely

file() reads a complete file into an array. fgetcsv() reads the next CSV record from an already open stream, which makes it a natural fit for a generator:

function readCsv(string $filename): Generator
{
    $handle = fopen($filename, 'rb');

    if ($handle === false) {
        throw new RuntimeException("Cannot open file: {$filename}");
    }

    try {
        while (($row = fgetcsv(
            stream: $handle,
            length: null,
            separator: ',',
            enclosure: '"',
            escape: '',
        )) !== false) {
            yield $row;
        }
    } finally {
        fclose($handle);
    }
}

foreach (readCsv('data.csv') as $row) {
    processRow($row);
}

Two details are easy to miss here.

First, the finally block closes the file after normal completion or an exception. It also handles cleanup when a generator is eventually destroyed after an early exit.

Second, passing escape: '' explicitly avoids relying on the deprecated default CSV escape behavior in PHP 8.4 and later.

This code does not make the entire PHP process use only a few kilobytes. The process still retains the stream buffer, parser state, generator frame, current record, and anything held by processRow(). What it avoids is memory growth proportional to the total number of CSV records.

That advantage disappears if the consumer immediately rebuilds the collection:

$rows = [];

foreach (readCsv('data.csv') as $row) {
    $rows[] = $row;
}

The producer is lazy, but the overall pipeline is not.

Why the usual memory benchmark is misleading

Consider this sequence:

$array = range(1, 1_000_000);
unset($array);

$start = memory_get_usage();

foreach (bigGenerator() as $number) {
    // Consume the values.
}

echo memory_get_peak_usage() - $start;

This measures the wrong thing for two separate reasons.

The first is timing: measuring current memory after a function returns tells us little about the peak reached while its array was alive.

The second is process-wide state. memory_get_peak_usage() remembers the highest point reached by the process. If the eager case runs first, a later generator case may report a peak increase of zero simply because it never exceeds the old array peak.

For the repository benchmark, I used a separate child process for every measured run. Each child resets peak accounting immediately before the workload, keeps the eager collection alive until measurement, and returns machine-readable results to the parent process.

Both modes must also prove that they did the same work. In this run they processed the same number of records and produced the same checksum.

The measured result

The input was a deterministic CSV fixture with 1,000,000 data records plus its header:

file size: 36.92 MiB;
rows processed: 1,000,001;
PHP: 8.5.9;
platform: Darwin arm64;
memory_limit: 1 GiB;
OPcache for CLI: off;
JIT: disabled;
one warm-up per mode;
ten measured runs per mode;
alternating eager/lazy execution order;
warm filesystem cache.

The two implementations produced the same checksum: 37,711,230.

Method	Median time	Time range	Median incremental peak memory
Array (eager)	0.759376 s	0.745849–0.829022 s	386.81 MiB
Generator (lazy)	0.658925 s	0.642476–0.679049 s	10.69 KiB

The memory result is the important one. The eager version materializes every parsed record as a PHP array, including all the per-element hash-table and zval overhead. The generator retains only the state needed for the current step and whatever the consumer keeps.

The timing result needs more restraint. In this run the generator completed about 13% faster, but yield is not inherently faster than array iteration. A generator suspends and resumes its execution frame for every value. On another workload, an already-built array may be faster to traverse.

Here, avoiding hundreds of MiB of allocation and cleanup outweighed the generator overhead. Different input, storage, PHP version, transformations, or consumer work can change that balance.

Generator, Iterator, or IteratorAggregate?

These APIs overlap, but I do not use them interchangeably.

I reach for a generator when the iteration is forward-only and fits naturally in one function:

function activeUsers(iterable $users): Generator
{
    foreach ($users as $user) {
        if ($user->isActive()) {
            yield $user;
        }
    }
}

The same Generator object cannot be rewound for another complete pass after it has advanced. Calling the generator function again creates a fresh generator.

I use IteratorAggregate when an object should be traversable more than once while keeping the iteration logic out of the object itself:

final class NumberRange implements IteratorAggregate
{
    public function __construct(
        private readonly int $start,
        private readonly int $end,
    ) {
    }

    public function getIterator(): Traversable
    {
        for ($number = $this->start; $number <= $this->end; $number++) {
            yield $number;
        }
    }
}

$range = new NumberRange(1, 5);

foreach ($range as $number) {
    echo $number . PHP_EOL;
}

Each foreach call asks the object for a new iterator, so this design is naturally reusable.

A custom Iterator is useful when cursor operations such as current(), next(), key(), valid(), and rewind() are part of the abstraction. It is more code, and I would not choose it merely to avoid writing a generator.

My practical rule is simple:

Situation	Default choice
One-pass stream or transformation pipeline	Generator
Reusable domain object that can be traversed	`IteratorAggregate`
Explicit cursor behavior is meaningful	`Iterator`
Random access or repeated indexed lookup	Array or another collection

Paginated APIs are lazy only between pages

A generator also works well around pagination:

function fetchCars(): Generator
{
    for ($page = 1; ; $page++) {
        $response = apiRequest('cars', ['page' => $page]);
        $items = $response['items'] ?? [];

        if ($items === []) {
            return;
        }

        foreach ($items as $car) {
            yield $car;
        }
    }
}

This prevents all pages from accumulating in one large array. It does not necessarily reduce memory to one car at a time: apiRequest() may buffer the complete HTTP response, and the decoded $items array remains alive while that page is being yielded.

The actual memory bound is therefore closer to one decoded page plus client and parser buffers. Page size still matters.

Where generators do not help

Generators are a poor fit when the consumer needs random access, frequent rewinds, sorting of the complete data set, or several passes over an expensive one-shot source.

They also cannot make a buffered source incremental. Wrapping a fully loaded array in a generator changes the interface, not the memory profile:

function pretendToStream(): Generator
{
    $rows = loadEveryRowIntoAnArray();

    foreach ($rows as $row) {
        yield $row;
    }
}

Database access has the same caveat. Yielding rows from a buffered query does not remove the driver's result buffer. To bound memory, the database driver and query mode must support incremental fetching as well.

Finally, laziness changes when errors occur. A generator function can be called successfully and then fail only after iteration begins. That is useful, but callers need to understand it.

Reproducing the benchmark

The complete benchmark, fixture generator, CSV and NDJSON examples, chart renderer, and tests are available here:

github.com/phpner/phpner-php-lazy-evaluation-demo

The recorded run can be reproduced with:

composer install
php bin/make_sample.php --rows=1000000
composer bench:record

Expect the timing numbers to move between machines and runs. The repository records the environment, row count, checksum, median, and range so those differences remain visible instead of being hidden behind one convenient number.

Conclusion

The benchmark changed how I phrase the recommendation. I do not choose a generator because yield is supposed to be fast. I choose it when the complete data set does not need to exist in memory at once.

For the measured CSV workload, that decision reduced incremental peak memory from 386.81 MiB to 10.69 KiB. The generator happened to be faster too, but memory behavior is the result I would expect to carry over to other genuinely streaming workloads.

The producer, parser, and consumer all have to participate. If any stage buffers the full data set, adding a generator somewhere in the middle will not fix the underlying problem.

The Hidden Path to Computers — Through the Lens of “Code” by Charles Petzold

Alex — Fri, 08 Aug 2025 08:51:48 +0000

📖 About the Book

Charles Petzold is an author who managed to explain the complex world of computer technology through compelling storytelling. His book Code: The Hidden Language of Computer Hardware and Software takes us on a journey from the earliest methods of communication to the modern digital computer — without dry technical jargon, but with real-world examples, metaphors, and historical facts.

"Computers are not magic. They are the result of a long human journey that began long before the invention of electronics."

1. How Humans Began to Communicate Information

Petzold begins by showing that people have always had the need to send messages across distances. At first, this meant using signal fires on hills, drums in the jungle, or flags on ships. Each of these methods had limits: in speed, distance, or the number of symbols available.

Eventually, we arrive at Morse code.

2. Morse Code: The First “Zeros” and “Ones”

Samuel Morse invented a system of short (dot) and long (dash) electrical signals. It was the first practical digital code — not literally zeros and ones, but conceptually very close: only two distinct signals used in combination to represent any letter or number.

📌 Key features:

Efficiency: The most common letters (like E and T) were assigned the shortest codes.
Messages were sent by completing or breaking an electrical circuit.
Telegraph operators could hear the code in real time and interpret it by ear.

“Morse code was the first system to show that any kind of information could be transmitted using just two types of signals.”

3. From Signals to Electricity

The telegraph was revolutionary for communication, but it only transmitted, not processed, information.

The next leap came with the realization that electric signals could do work — they could control machines, and ultimately, perform logic.

Here, Petzold introduces the relay — a simple switch that opens or closes in response to electrical current. It too has two states, which fits naturally into binary logic.

4. The Binary Number System

For a machine to "understand" anything, it must be able to represent numbers and instructions.

The binary system (0 and 1) turned out to be ideal:

0 = off
1 = on

Historically, the binary number system was described by Gottfried Wilhelm Leibniz in the 17th century. But with the invention of electrical switches, it became practically useful.

5. Logic Gates and Circuits

Petzold shows that using relays, you can build basic logic gates:

AND
OR
NOT

By combining these, you can construct any computation. This leads to the central insight:

A computer is essentially a massive network of binary switches arranged in logical combinations.

6. From Mechanical Devices to Electronics

Before relays, there were mechanical calculators — like Charles Babbage’s Analytical Engine. But they were slow, bulky, and unreliable.

Eventually, vacuum tubes and transistors replaced relays, making computations faster and more compact.

7. Encoding Text, Images, and Sound

Once you can handle numbers, you can represent anything:

Text: through ASCII, where each letter has a unique binary number.
Images: grids of black/white pixels, each encoded as 0 or 1.
Sound: sequences of numbers representing waveform amplitudes.

This showed that all information — visual, audio, textual — could be reduced to binary.

8. Programs and Memory

After machines could store and manipulate binary data, they needed instructions — programs.

Memory began to store both data and instructions, which led to the concept of the Von Neumann architecture, where program and data coexist in the same memory space.

9. The Big Realization

By the end of the book, the reader understands:

A computer is not a magical box. It’s a machine built from simple components (relays, switches, transistors) that operate on binary logic.
Complexity arises from the clever arrangement of simple building blocks.

“A computer is nothing more than a very fast and very obedient idiot doing exactly what we tell it to.”

🎯 Why This Book Is Valuable

It gives you an intuitive understanding of how computers work — without formulas.
It shows a clear historical progression: signal fires → Morse code → relays → transistors → processors
After reading it, you begin to see technology as a chain of brilliant simplifications, rather than complexity.

DEV Community: Alex

The Background-Tab Bug I Missed in My JavaScript Polling Code

First, prove that a timer is not a clock

An interval is a request, not a clock

Give the page a return path

The race I nearly missed

Animation frames should render state

WebSockets need resynchronisation too

What I would ship

Further reading

PHP Profiling: What the Numbers Actually Tell Us

What are we trying to improve?

Profile one case deliberately

A fixture that exercises the code

Benchmark protocol

Results

What did the set actually improve?

The fast regex is not the same validator

Why the original progression was misleading

How to reproduce it

Conclusion

Further reading

Lazy Evaluation in PHP: Real‑World Memory Savings with Generators

What “lazy” means here

Streaming a CSV safely

Why the usual memory benchmark is misleading

The measured result

Generator, Iterator, or IteratorAggregate?

Paginated APIs are lazy only between pages

Where generators do not help

Reproducing the benchmark

Conclusion

Further reading

The Hidden Path to Computers — Through the Lens of “Code” by Charles Petzold

📖 About the Book

1. How Humans Began to Communicate Information

2. Morse Code: The First “Zeros” and “Ones”

📌 Key features:

3. From Signals to Electricity

4. The Binary Number System

5. Logic Gates and Circuits

6. From Mechanical Devices to Electronics

7. Encoding Text, Images, and Sound

8. Programs and Memory

9. The Big Realization

🎯 Why This Book Is Valuable