Using Xdebug for Real-World PHP Debugging and Profiling: Key Takeaways from “Are you using debugger and why not?” by Borislav Lazendic (TimeTac)

Why this session matters

In “Are you using debugger and why not?”, Borislav Lazendic (TimeTac) makes a pragmatic case for making Xdebug a default part of PHP development. The talk is light on hype and heavy on practical examples: late-start debugging for long-running scripts, profiling that spotlights real hotspots, and tiny code decisions that cut memory and runtime in half. The upshot is simple: avoiding Xdebug is often self-defeating.

From the DevJobs.at editorial seat, we captured the technical throughline of the session so you can replicate the wins in your own code.

The perceived blocker: “Debugging slows me down” — solved for long-running scripts

A common reason teams shy away from debuggers is long-running jobs. If a process already takes an hour, nobody wants to wait two or three hours stepping through it. Lazendic addresses exactly that concern with a capability available since Xdebug 3.1:

• Start the debugging session late, at the point you care about. If your goal is to inspect something near the end of the script, Xdebug can begin the session only when execution reaches that location. You don’t pay the time penalty for the rest of the run.

This removes a major practical barrier. Debugging doesn’t have to mean walking through the entire script in slow motion. You can attach exactly where the question is.

Beyond breakpoints: Xdebug as a profiler

Xdebug is not just about stepping through code. Lazendic zeroes in on profiling — a feature many teams underuse. He demonstrates a small program with four functions: two essentially do nothing, one generates an array of 10,000 items. The goal is to understand what to look at in the profiler.

• Tools: PhpStorm can load Xdebug profiler snapshots. Alternatively, you can use Cachegrind to inspect the output. Lazendic uses both.
• Metrics that matter: Focus on “own time” and “own memory.” You want to know which parts of your code consume time and memory by themselves, not only via callers. That’s where optimization effort pays off.

In the demo, the conclusion is intuitive yet essential: the function that actually generates the large array eats almost all time and memory. Profilers replace gut feelings with evidence about where work really happens.

Real-world pattern 1: Chunking slashes memory usage

Arrays dominate the talk’s practical examples — and for good reason. Lazendic contrasts two versions of the same idea and prints memory usage directly from PHP at the end of execution.

• Variant A: Generate an array with 100,000 items and “process” it (with no real work in the processing step). Result: about 4 MB of memory used when the script finishes.
• Variant B: Work in chunks: generate and process 20,000 items five times. Result: roughly 1.x MB at the end, with a peak around 2 MB.

The micro-demo keeps numbers small, but the impact scales. Lazendic mentions a production improvement from 130 MB down to 90 MB by chunking a large array path. The lesson holds: when your code naturally forms big batches, chunking often gives you significant headroom with minimal refactoring.

Why chunking works

• You keep less data alive at once, lowering end-of-run memory and peak usage.
• Lower peaks reduce the risk of hitting memory limits.
• Aggregated work becomes smoother, often without changing business logic.

If your path involves large aggregates, make chunking a default consideration.

Real-world pattern 2: Pass arrays by reference when mutating — halve memory costs

Lazendic’s second example: both variants generate 100,000 items, but now the processing step adds one more element to the array.

• Without passing by reference: about 8 MB of memory.
• With passing by reference: about 4 MB.

Explanation: if you pass an array into a function and mutate it (e.g., append an item), PHP copies the array and applies the change to the copy, effectively doubling the memory footprint. If you pass it by reference, the operation modifies the original array and avoids the duplication.

For small arrays this might not matter. But the habit of ignoring array semantics tends to backfire exactly when arrays become huge — typically the moment you hit a memory limit and scramble to profile. Make data flow decisions explicit where mutation happens.

Real-world win: 30% faster by removing an unnecessary function

A brief profiling session on a simple endpoint revealed an unexpected culprit: a function that consumed 30% of the request time without adding value. Removing it delivered an immediate 30% speed-up for that request. This is the kind of win you only get by looking — it’s hard to guess that a no-op is burning a third of your budget.

Debugging to understand legacy code — not just to fix bugs

Lazendic also uses debugging sessions to learn unfamiliar or rarely touched code paths. Stepping through lets him see “approximate values” and types of variables at runtime, which quickly demystifies the behavior of legacy flows.

A concrete case: he needed to introduce a new authorization workflow. Starting from an existing flow, he debugged through it to observe how it behaves, then designed the second flow accordingly. Debugging doubled as living documentation of the real system.

Team habit: once adopted, it’s hard to go back

Lazendic notes that across teams and departments, colleagues who use Xdebug would never start a new project without it. That’s not a quantitative survey, but a clear observation about habit and payoff: once developers internalize the value, the tool becomes part of muscle memory.

The debate: a provocative tweet — and a better phrasing

The talk’s origin story traces back to a heated Twitter and Reddit discussion sparked by a blunt tweet from Xdebug’s founder:

Unsurprisingly, that ruffled feathers. A follow-up softened and clarified the point in a way Lazendic endorses:

The second sentence captures the essence without alienating people. It also encapsulates the talk’s practical philosophy: refusing to use Xdebug cuts you off from easy wins in debugging, profiling, and learning your system’s real behavior.

How to put these ideas into practice

The talk sketches a straightforward playbook. No new frameworks, no sprawling refactors — just measurable steps and targeted interventions.

1) Debug long-running scripts without paying the full time cost

• Use the Xdebug 3.1 capability to start the debugging session only when code reaches the point you actually care about. This lets you inspect hour-long processes without slowing down the first 59 minutes.
• Place breakpoints where decisions crystallize: at the end of pipelines, before persisting changes, or right before output.

2) Make profiling routine

• Create profiler snapshots for representative requests and CLI jobs. Load the Xdebug dumps in PhpStorm or analyze them with Cachegrind.
• Focus on “own time” and “own memory.” Hunt the functions that truly dominate resources.
• Agree as a team when profiling is mandatory (e.g., before merging larger refactors or when introducing paths that deal with big arrays).

3) Default to chunking for big arrays

• If you handle 100,000 items (or far more) in one go, evaluate whether chunking is viable. The talk’s figures — ~4 MB vs. ~1.x MB at end, ~2 MB peak — illustrate the leverage.
• Watch peak memory: it’s often the limiting factor even when end-of-run numbers look fine.

4) Pass by reference when you mutate arrays

• When a function modifies the array, pass by reference to avoid implicit copying. Lazendic’s demo showed a clean 2× difference: ~8 MB vs. ~4 MB.
• Make mutation explicit. Be clear which functions change state and adopt reference passing precisely there.

5) Systematically capture quick wins

• Run short profiling sessions for slow endpoints and scan for outliers in “own time.” As the talk’s 30% example shows, removing a useless function can be the biggest optimization.
• Leave a short note in PRs describing the profiling result and the hotspot you addressed. This guards against regressions and builds a shared performance narrative.

6) Use debugging to onboard and explore

• When taking over a legacy area, start a debugging session, step through once, and note the real variable types and values. That half-hour can save days of misunderstandings later.
• Use runtime inspection to validate assumptions: Are data shapes what you expect? Do all branches execute? Are edge cases visible?

What the measurements really say

The talk’s numbers aren’t universal benchmarks, but they demonstrate consistent principles:

• Large arrays dominate both time and memory in many PHP paths.
• Chunking lowers end-of-run memory and, crucially, peak usage — the typical point of failure at memory limits.
• Mutating arrays without reference doubling memory is fine for small cases and dangerous for large ones.
• Short, targeted profiling sessions surface surprises. Sometimes 30% of your budget goes to code you don’t need.
• Debugging is also a learning tool. It reveals how the system behaves, not just how we imagined it.

Common misconceptions — and how this talk counters them

• “Debuggers are only for hard bugs.” Not really. In this session, debugging shines as a way to understand code and design changes (e.g., the authorization workflow case).
• “Profiling is for fires.” Quick snapshots answer whether you’re working in the right area before you burn time optimizing the wrong thing.
• “References make code messy.” They make intent explicit when mutation is required — and the memory savings justify being deliberate.

A pragmatic checklist for your next PR

• Do you handle large arrays on this path? Can you switch to chunking?
• Do any functions mutate passed arrays? If yes, are you using reference passing?
• Do you have a profiler snapshot? What do “own time” and “own memory” say about hotspots?
• Is the path long-running? Consider starting debugging late to avoid time penalties.
• Any redundant calculations or unnecessary functions? Can you remove them first?
• Are you landing a refactor that changes data flow? Profile before merge.

These prompts push teams toward measurable answers — exactly where Xdebug adds everyday value.

Conclusion: “Do yourself a favor” — make Xdebug a default

Borislav Lazendic’s “Are you using debugger and why not?” (TimeTac) is a grounded tour of Xdebug’s practical strengths. Late-start debugging removes the time penalty for long-running scripts. Profiling around “own time” and “own memory” takes you straight to true hotspots. Chunking and passing by reference produce tangible gains — from double-digit percent speed-ups to shedding dozens of megabytes.

The follow-up to that contentious tweet sums it up:

We agree. Not as dogma, but as a sensible default: use Xdebug to debug where you’re unsure, and profile where you need evidence. The barriers are smaller — and the wins larger — than many teams expect. For at least one developer in the audience, as Lazendic hopes, adopting Xdebug may be a small step that pays off outsized dividends in day-to-day engineering.

• 

  

  How to pick the next Front End Framework

  Tomi Močnik von TimeTac zeigt in seinem devjobs.at TechTalk wie die Entscheidung für ein neues Front End Framework im Unternehmen gefallen ist und welche Erfahrungen dabei gemacht wurden.

  Watch now
• 

  

  TimeTac Connect, How we handle Integrations

  Anna Kastner von TimeTac erzählt in ihrem devjobs.at TechTalk darüber, wie das Devteam an die Challenges von Integrations herangegangen ist.

  Watch now
• 

  

  Challenges in mobile application development

  Ludwig Blaikner von TimeTac spricht in seinem devjobs.at TechTalk über den Weg, wie das Team ein Design Proposal zu einer funktionierenden Mobile Software gebaut hat.

  Watch now