Xdebug richtig einsetzen: Debugging und Profiling in PHP – unsere Learnings aus „Are you using debugger and why not?“ von Borislav Lazendic (TimeTac)

Warum dieser Vortrag hängen bleibt

In seiner Session „Are you using debugger and why not?“ zeigte Borislav Lazendic (TimeTac) sehr konkret, wie viel Produktivitätsgewinn in konsequent genutzten Debugging- und Profiling-Tools steckt. Statt abstrakter Appelle brachte er eine Reihe greifbarer Beispiele aus PHP-Projekten mit Xdebug – inklusive realer Messwerte, typischer Fallstricke und einer einfachen, aber entscheidenden Message: Wer Xdebug meidet, nimmt sich selbst Chancen.

Wir bei DevJobs.at haben die Session verfolgt und die wichtigsten technischen Einsichten zusammengetragen – mit Fokus darauf, wie ihr sie unmittelbar in eurem PHP-Alltag einsetzen könnt.

Die Hürde: „Debugger verlangsamen meinen Flow“ – und warum das nicht zählen muss

Ein häufiges Gegenargument gegen Debugger: Lange laufende Skripte. Wenn ein Prozess ohne Debugging schon eine Stunde dauert, will niemand riskieren, dass er mit Breakpoints plötzlich zwei oder drei Stunden braucht. Genau diese Sorge adressiert Lazendic – mit einem Feature, das seit Xdebug 3.1 verfügbar ist.

• Xdebug kann die Debugging-Session erst an einem späten Punkt starten: Wenn ihr lediglich am Ende eines Skripts etwas untersuchen wollt, startet die Session erst dann, wenn der Code besagte Stelle erreicht. Die Laufzeit des restlichen Skripts bleibt unbeeinflusst.

Damit ist ein zentraler Pain Point erledigt: Debugging muss nicht mehr bedeuten, dass eine gesamte Langläufer-Route im Zeitlupentempo durchschreitet. Ihr könnt gezielt dort einhaken, wo es zählt.

Debugging ist nur der Anfang: Xdebug als Profiling-Werkzeug

Lazendic betont, dass Xdebug mehr kann als Step-Debugging. Ein unterschätztes Schwergewicht ist das Profiling. Er zeigt eine kleine Beispielapplikation mit vier Funktionen – zwei davon tun praktisch nichts, eine dritte erzeugt ein Array von 10.000 Einträgen. Das Ziel: die Oberfläche und die Auswertung verstehen.

• Tools: In PhpStorm lässt sich ein Profiler-Snapshot von Xdebug bequem laden. Alternativ eignet sich Cachegrind, falls man eine eigenständige Auswertung bevorzugt. Lazendic arbeitet selbst mit beiden Varianten.
• Wichtige Metriken: „Own time“ und „own memory“ sind die Leitplanken. Die Frage lautet: Welche Funktionen verbrauchen die meiste Zeit und den meisten Speicher – und zwar eigenständig, nicht nur transitiv über Aufruferketten? Genau dort lohnt sich die Optimierung.

Im Demonstrationsbeispiel bestätigt sich das Offensichtliche: Die Funktion, die das große Array erzeugt, dominiert Zeit und Speicher – ein klarer Hinweis, wo Optimierung überhaupt einen Effekt hat. So simpel das klingt: Das Profiling-Interface zwingt uns zu evidenzbasierten Entscheidungen statt Bauchgefühl.

Praxisbeispiel 1: Chunking senkt den Speicherbedarf – deutlich

Ein wiederkehrendes Muster im Vortrag: Große Arrays sind tückisch. Lazendic zeigt zwei Varianten desselben Problems – und vergleicht den Speicherverbrauch, den er direkt in PHP ausgibt.

• Variante A: Ein Array mit 100.000 Einträgen wird erzeugt und anschließend „verarbeitet“, wobei die Verarbeitung in diesem Beispiel tatsächlich nichts tut. Ergebnis: ca. 4 MB Speicherverbrauch zum Ende des Skripts.
• Variante B: Dieselben 100.000 Einträge werden in fünf Durchläufen à 20.000 Einträge erzeugt und verarbeitet (Chunking). Ergebnis: Rund 1,x MB am Ende und ein Peak von etwa 2 MB.

Der Effekt wirkt im Demo-Setup klein, skaliert in realen Codebasen aber spürbar. Lazendic nennt eine konkrete Verbesserung aus der Praxis: von 130 MB auf 90 MB – allein durch Chunking an einer Stelle mit sehr großen Arrays. Klar ist auch: Wenn in euren Projekten ähnliche Strukturen vorkommen, sind dort oft mit erstaunlich wenig Umbau mehrere Dutzend Megabyte einzusparen.

Warum Chunking funktioniert

• Speicher wird in kleineren Portionen genutzt und früher wieder freigegeben.
• Die Spitzenlast (Peak) sinkt – ein häufiges Nadelöhr nahe an Memory Limits.
• In Summe landen deutlich weniger gleichzeitige Daten im Arbeitsspeicher.

Das Fazit: Wer mit großen Datenmengen arbeitet, sollte Chunking früh als Standardoption mitdenken.

Praxisbeispiel 2: Übergabe per Referenz halbiert den Speicher – wenn ihr Arrays mutiert

Noch ein Beispiel aus der Session: Wieder 100.000 Einträge, diesmal wird in der „Verarbeitung“ tatsächlich ein Element zum Array hinzugefügt. Das Ergebnis ist aussagekräftig:

• Ohne Referenzübergabe: ca. 8 MB Speicherverbrauch.
• Mit Referenzübergabe: ca. 4 MB.

Die Begründung ist geradlinig: Wird ein Array an eine Funktion übergeben und innerhalb dieser Funktion verändert (z. B. ein Eintrag hinzugefügt), kopiert PHP das bestehende Array und nimmt die Änderung an der Kopie vor. Effekt: ungefähr doppelter Speicherbedarf. Wird das Array hingegen per Referenz übergeben, wird kein zusätzliches Duplikat angelegt; die Änderung erfolgt am Original.

Lazendic schränkt ein: Bei kleinen Arrays ist der Effekt oft vernachlässigbar. Aber genau deshalb übersehen Teams den Kipppunkt – bis das Memory Limit reißt. Dann beginnt hektisches Profiling. Besser: Proaktiv entscheiden, wie Daten fließen sollen – vor allem bei mutierenden Funktionen.

Praxisbeispiel 3: 30 % Laufzeit gespart – durch das Entfernen einer überflüssigen Funktion

Ein besonders greifbarer Nutzen eines kurzen Profiling-Laufs: In einem realen Endpoint entdeckte das Team eine Funktion, die 30 % der gesamten Anfragedauer fraß – ohne tatsächlichen Nutzen. Das Entfernen dieser Funktion brachte unmittelbar 30 % Zeitgewinn für genau diesen Request.

Man braucht dafür keine aufwendige, monatelange Performance-Offensive. Ein gezielter Profiler-Snapshot und wenige Minuten Analyse reichen manchmal, um die kostbarste Optimierung zu identifizieren: die, die gar nicht erst stattfinden müsste.

Debugging als Lernwerkzeug: Legacy-Code verstehen, ohne zu spekulieren

Lazendic nutzt Debugging nicht nur, um Fehler zu finden, sondern um unbekannte oder wenig berührte Codepfade zu verstehen. Wenn er durch eine Legacy-Stelle navigiert, helfen ihm Debugging-Sessions, die „ungefähren Werte“ und die Typen von Variablen zu sehen – also das, was wirklich passiert, statt das, was die Benennung vermuten lässt.

Ein konkreter Fall aus seiner Praxis: Er musste einen neuen Workflow in die bestehende Autorisierung integrieren. Ausgangspunkt war ein vorhandener Workflow. Über Debugging hat er gesehen, wie dieser verläuft, welche Werte unterwegs entstehen – und anschließend den zweiten, benötigten Workflow kohärent entworfen. Kurz: Debugging als Dokumentation der Realität.

Teamkultur: „Sie würden nie ohne starten“

Lazendic schildert, dass Xdebug für seine Kolleginnen und Kollegen zum Standard geworden ist – über Teams und Abteilungen hinweg. Wer sich an die Vorteile gewöhnt hat, beginnt neue Projekte nicht mehr ohne. Diese Beobachtung ist keine statistische Studie, sondern eine klare Team-Erfahrung: Gewohnheit trifft auf spürbare Wirkung.

Die Debatte: „Amateure“ – und ein wichtiges Nachwort

Auslöser für den Talk war eine hitzige Diskussion auf Twitter und Reddit. Ein Tweet des Xdebug-Gründers formulierte scharf:

Die Wellen schlugen hoch. In einem Nachsatz wurde der Punkt differenzierter und, wie Lazendic sagt, „in nicer words“ formuliert:

Dieser zweite Satz bringt es auf den Punkt, ohne zu brüskieren. Er fasst auch Lazendics Haltung zusammen: Wer konsequent darauf verzichtet, vergibt Chancen – bei der Fehlersuche, beim Performance-Tuning und beim Lernen über den eigenen Code.

Konkrete Anwendung: So übertragt ihr die Learnings auf euren Code

Die Beispiele im Talk liefern eine klare Roadmap. Ohne neue Frameworks, ohne invasive Umbauten – dafür mit bewussten Messungen und gezielten Eingriffen.

1) Lange Skripte debuggen – ohne Zeit zu verlieren

• Nutzt das Xdebug-Feature ab Version 3.1, um die Debugging-Session erst an einer gewünschten Stelle zu starten. So könnt ihr auch einstündige Prozesse untersuchen, ohne die ersten 59 Minuten zu verlangsamen.
• Setzt Breakpoints dort, wo Entscheidungen fallen oder Daten kippen – am Ende einer Verarbeitungskette, kurz vor einem Persist-Schritt oder direkt vor der Ausgabe.

2) Profiling in den Arbeitsalltag integrieren

• Erstellt Profiler-Snapshots für repräsentative Requests oder CLI-Jobs. Nutzt entweder PhpStorm zum Laden der Xdebug-Dumps oder analysiert sie mit Cachegrind.
• Konzentriert euch auf „own time“ und „own memory“. Sucht die Hotspots, an denen eure Eingriffe den größten Effekt haben.
• Legt im Team Kriterien fest, wann ein Profiling Pflicht ist (z. B. vor dem Merge von größeren Refactorings oder bei neuen Datenströmen mit großen Arrays).

3) Chunking als Default-Überlegung bei großen Arrays

• Wenn ihr 100.000 (oder deutlich mehr) Einträge am Stück verarbeitet, prüft, ob sich das Problem in Chunks zerlegen lässt. Die im Talk genannten Messwerte – 4 MB vs. ca. 1,x MB Endverbrauch und 2 MB Peak – illustrieren das Potenzial.
• Behaltet die Peak-Nutzung im Auge. Sie ist oft entscheidender als der Endverbrauch, wenn ihr Memory Limits berührt.

4) Mutierende Funktionen: Arrays per Referenz übergeben

• Sobald eine Funktion das Array verändert, ist Referenzübergabe die pragmatischere Wahl – sonst droht eine implizite Verdopplung des Speicherbedarfs. Der Demo-Effekt im Talk: 8 MB vs. 4 MB.
• Achtet darauf, wo ihr tatsächlich mutiert, und macht diese Stellen explizit. So wird Referenzübergabe bewusst eingesetzt und nicht versehentlich weggelassen.

5) „Quick Wins“ systematisch heben

• Führt kurze Profilings für langsame Endpoints durch und scannt gezielt nach Funktionen mit überproportionaler „own time“. Lazendics Beispiel zeigt: 30 % lassen sich manchmal einfach dadurch sparen, dass man Unnötiges entfernt.
• Dokumentiert solche Befunde kurz im PR. Das hilft, Wirkung und Notwendigkeit sichtbar zu machen und verhindert, dass Optimierungen versehentlich rückgängig gemacht werden.

6) Debugging als Onboarding- und Explorationswerkzeug nutzen

• Wenn ihr eine Legacy-Stelle übernehmt: Startet eine Debugging-Session, lauft einmal durch und notiert die realen Typen und Werte. Diese 30 Minuten zahlen sich im weiteren Verlauf vielfach aus.
• Nutzt die Session, um Hypothesen zu verifizieren: Entspricht die tatsächliche Datenform den Erwartungen? Werden alle Pfade durchlaufen? Sind Sonderfälle sichtbar?

Was ihr aus den Messbeispielen mitnehmen könnt

Die Zahlen aus dem Talk sind keine universellen Benchmarks – aber sie illustrieren stabile Prinzipien:

• Große Arrays sind der Hebel: Sie beeinflussen Zeit und Speicher oft stärker als alles andere im Codepfad.
• Chunking reduziert sowohl den Endverbrauch als auch den Peak – letzterer ist oft die wahre Schmerzgrenze.
• Mutierende Operationen an Arrays ohne Referenz kosten doppelt Speicher. Das ist in kleinen Fällen egal, in großen Fällen fatal.
• Einfache Profilerläufe finden Überraschungen. Eine einzelne, überflüssige Funktion kann 30 % einer Anfrage verschlingen.
• Debugging ist nicht nur Fehlerjagd: Es ist ein Werkzeug, um komplexe Systeme zügig zu verstehen.

Typische Missverständnisse – und wie ihr sie ausräumt

• „Debugger sind nur etwas für schwierige Bugs“ – Nein. Sie sind ebenso ein Lern- und Designwerkzeug. Lazendics Beispiel mit der Autorisierung zeigt: Wirklicher Code schlägt jede Annahme.
• „Profiling lohnt sich nur bei Performance-Krisen“ – Im Gegenteil. Kurze, gezielte Profilings geben schnelle Gewissheit, ob ihr auf der richtigen Baustelle arbeitet.
• „Referenzen machen Code unübersichtlich“ – Sie machen Absichten sichtbar, sofern ihr sie dort einsetzt, wo Mutationen explizit gewollt sind. Der Speichergewinn rechtfertigt diese Klarheit.

Kleine Entscheidungen, große Wirkung: Unsere Checkliste für das nächste Ticket

• Gibt es im Codepfad große Arrays? Falls ja, ist Chunking möglich und sinnvoll?
• Werden Arrays in einer Funktion verändert? Falls ja, wird per Referenz übergeben?
• Ist ein schneller Profiler-Snapshot vorhanden? Was sagen „own time“ und „own memory“ zu den Hotspots?
• Handelt es sich um einen Langläufer? Wenn ja, Debugging erst am Zielpunkt starten.
• Gibt es redundante Berechnungen oder unnötige Funktionen im Pfad? Kann etwas gestrichen werden?
• Steht ein Refactoring an, das Datenflüsse ändert? Dann Profiling vor dem Merge einplanen.

Diese Fragen zwingen zu messbaren Antworten – genau das, was Xdebug im Alltag so wertvoll macht.

Fazit: „Tut euch selbst den Gefallen“ – und nutzt Xdebug bewusst

Die Session „Are you using debugger and why not?“ von Borislav Lazendic (TimeTac) liefert praktische Argumente statt Dogmen: Spätes Starten der Debugging-Session nimmt Langläufern den Schrecken. Profiling über „own time“ und „own memory“ weist zuverlässig zu den echten Hotspots. Chunking und Referenzübergabe bringen in der Praxis fühlbare Einsparungen – bis hin zu zweistelligen Prozentgewinnen in der Laufzeit oder Dutzenden Megabytes an Speicher.

Der zitierte Nachsatz zur Debatte trifft den Kern:

Wir schließen uns an – nicht als kategorisches Muss, sondern als klare Empfehlung: Nutzt Xdebug als Standardwerkzeug. Debuggt dort, wo ihr Lernbedarf habt. Profiliert dort, wo ihr Bauchgefühl durch Messwerte ersetzen wollt. Die Hürden sind kleiner, die Wirkung ist größer, als viele vermuten. Und für mindestens eine Entwicklerin oder einen Entwickler im Publikum – so Lazendic – ist der Schritt vielleicht klein, aber für die eigene Karriere bedeutsam.

• 

  

  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.

  Jetzt ansehen
• 

  

  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.

  Jetzt ansehen
• 

  

  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.

  Jetzt ansehen