Zusammenfassung

Diese PEP schlägt die Erstellung eines neuen Standardbibliotheksmoduls namens profiling vor, um die integrierten Python-Profiling-Tools unter einem einzigen, kohärenten Namensraum zu organisieren.

Diese PEP schlägt außerdem die Veralterung des profile-Moduls vor, eines klassischen reinen Python-Tracing-Profilers.

Motivation

Python wird derzeit mit zwei Tracing-Profilern ausgeliefert: profile und cProfile. Das profile-Modul ist in reinem Python implementiert und ist größtenteils didaktisch oder für die Unterklassifizierung nützlich, aber für reale Anwendungen zu langsam. cProfile hingegen ist in C implementiert und besser für praktische Profiling-Szenarien geeignet, obwohl es aufgrund einiger Verhaltensunterschiede kein Drop-in-Ersatz für profile ist.

Beides sind Tracing-Profiler, d.h. sie instrumentieren jeden Funktionsaufruf und -rücksprung. Diese Methodik führt zu erheblichen Laufzeit-Overheads und kann bestimmte Interpreter-Optimierungen deaktivieren, wie z.B. solche, die durch PEP 659 eingeführt wurden. Darüber hinaus beobachtet cProfile nur den Hauptthread, was ihn in modernen parallelen Python-Programmen weniger nützlich macht. Verwirrenderweise impliziert die Benennung dieser Module, dass profile kanonisch ist, obwohl es tatsächlich weitgehend veraltet ist.

Mit Python 3.15 wurde ein neuer Sampling-Profiler unter profile.sample eingeführt. Dieses Werkzeug, bekannt als tachyon, verwendet statistisches Sampling, um Leistungseigenschaften abzuleiten, was zu Zero-Overhead-Profiling führt und besser mit dem modernen Python-Interpreter funktioniert. Es unterstützt auch Multithreading, asynchrone Funktionen, freie Threading-Builds und das Anhängen an laufende Prozesse. Trotz dieser Stärken ist die Platzierung von tachyon unter profile.sample irreführend und verschleiert seine Bedeutung.

Derzeit mangelt es der Organisation von Profiling-Tools an einer konsistenten, auffindbaren Struktur. Die vorgeschlagene Reorganisation soll die Benutzer effektiver zu geeigneten Werkzeugen leiten, methodische Unterschiede zwischen Profilern verdeutlichen und den Grundstein für zukünftige Erweiterungen legen.

Begründung

Diese Reorganisation adressiert mehrere langjährige Probleme mit Pythons Profiling-Tools.

Erstens verbessert sie die Auffindbarkeit, indem alle integrierten Profiler unter einem einzigen, klar benannten Namensraum zusammengefasst werden. Derzeit sind Profiling-Tools über Module mit inkonsistenten Namen und unklaren Beziehungen verstreut. Durch die Einführung des profiling-Moduls erhalten Benutzer einen klar definierten und intuitiven Ort, um Profiling-Funktionalität zu erkunden und darauf zuzugreifen.

Zweitens verbessert der Vorschlag die Klarheit, indem die Untermodule nach ihrer zugrundeliegenden Methodik benannt werden – profiling.tracing für deterministische Tracing-Profiler und profiling.sampling für statistische Sampling-Profiler. Diese explizite Kategorisierung erleichtert das Verständnis des Verhaltens und der Einschränkungen jedes Werkzeugs und richtet die API an dem Denkmodell aus, das die Benutzer annehmen sollen.

Drittens bietet sie Anleitung für Entwickler, indem die empfohlenen Werkzeuge leichter zu finden und zu verwenden sind. Die aktuelle Struktur kann Benutzer dazu verleiten, sich auf veraltete oder weniger performante Module wie profile zu verlassen, nur aufgrund der Namenshierarchie. Mit dem profiling-Namensraum und seiner klareren Semantik ist es wahrscheinlicher, dass Benutzer den geeigneten Profiler für ihren spezifischen Anwendungsfall wählen, sei es für Sampling mit geringem Overhead oder detailliertes Tracing.

Schließlich fördert diese Struktur die Erweiterbarkeit. Durch die Konsolidierung von Profiling-Tools unter einem einheitlichen Namensraum wird es einfach, zukünftige Profiling-Funktionen – wie Speicherprofiler, I/O-Profiler oder Hybrid-Tools – einzuführen, ohne überlastete Module zu belasten oder redundante Top-Level-Namen hinzuzufügen. Das profiling-Modul bietet hierfür einen natürlichen Ort.

Spezifikation

Dokumentation

Die Python-Dokumentation wird das neue Modul profiling als kanonischen Einstiegspunkt für Profiling-Funktionalität verwenden. Sie wird auch die Unterscheidung zwischen Tracing- und Sampling-Profilern erläutern und Anleitungen enthalten, wann jeder Typ am besten geeignet ist.

Die Dokumentation für cProfile bleibt verfügbar, wird aber auf die neuen profiling-Entsprechungen verlinken.

Abwärtskompatibilität

Der einzige abwärtsinkompatible Aspekt dieser PEP ist die zukünftige Entfernung des profile-Moduls, dies wird jedoch nach dem Verfahren von PEP 387 erfolgen.

Sicherheitsimplikationen

Keine.

Abgelehnte Alternativen

Urheberrecht

Dieses Dokument wird in die Public Domain oder unter die CC0-1.0-Universal-Lizenz gestellt, je nachdem, welche Lizenz permissiver ist.