it-swarm.com.de

Bereinigen von WordPress, um die Leistung zu verbessern?

Wenn man sich die aktuelle WordPress-Codebasis ansieht, ist klar, dass Funktionen überlastet sind. Ich zähle über 8.100 Funktionen/Methoden, die in der WordPress-Codebasis definiert sind. Das ist schrecklich und ein schrecklicher Einsatz von Ressourcen.

Das Problem mit so vielen Funktionen (oder Klassen) ist, dass WordPress nicht DRY ist (wiederholen Sie sich nicht) und ich bin sicher, dass viele dieser Blöcke mit besseren Mustern kombiniert oder ersetzt werden könnten .

Wir brauchen jedoch eine Möglichkeit, die aktuelle API (alle diese Funktionen) zu puffern, damit wir beginnen können, den Back-End-Code zu kombinieren, ohne dass sich die (lose verwendete) "Schnittstelle" ändert.

Die Lösung?

PHP 5 & 6 hat SPL Autoloading von Klassen. Mit dieser Funktion kann PHP warten, bis eine Klasse benötigt wird, bevor sie geladen wird. Dies verhindert verschwendete Ressourcen da nicht verwendete Funktionen/Dateien erst geladen werden, wenn sie benötigt werden.

Leider kann WordPress dies nicht verwenden, da "Autoloading" in PHP nur für Klassen funktioniert. Und WordPress ist ein Berg von Funktionen.

Ich suche nach Möglichkeiten und Herausforderungen, um die WordPress-Codebasis zu bereinigen, und dies scheint die größte zu sein.

Da WordPress so viele Funktionen für Plugin/Theme-Entwickler erstellt hat (anstatt Klassen verfügbar zu machen), scheint es keine Möglichkeit zu geben, diese tiefe Lücke zu schließen, ohne Tausende von Themes und Plugins zu zerstören.

Die einzige Idee, die mir einfiel, war, ein Skript zu schreiben, das sich alle Funktionen ansieht und sie in Klassen konvertiert, die dann automatisch geladen werden können. An ihrer Stelle würden Shell-Funktionen zurückbleiben, die als Class-I-Fied-Version der Funktion bezeichnet werden.

Etwas wie das:

function wp_foo_bar() {
    call_user_func_array(array('foo' => __FUNCTION__), func_get_args());
}

Hat jemand versucht, die WordPress-Codebasis zu bereinigen? Gibt es andere Probleme mit diesem Ansatz?

Update zur Klärung

Die Umstellung des Systems auf Autoloading ist der erste Schritt, mit dem wir eine bessere Kontrolle über die Auslastung der Ressourcen und die Anordnung der Fassaden erlangen können, wenn wir einige der Kernfunktionen in bessere Designs migrieren. Es ist viel schwieriger, Funktionen abzuschreiben. Daher beginnt diese Frage mit dem erneuten Schreiben des Systems.

Wenn wir hier aufhören - dann haben wir möglicherweise einen Nettoleistungsverlust, weil wir die gleiche Anzahl von Funktionen haben - und jetzt beginnen auch die Klassen mit dem automatischen Laden.

Daher hat dies nichts mit prozeduralem Code zu tun vs OOP . Es geht darum, die API am besten gegen Änderungen am gesamten System zu puffern. Das derzeitige WordPress-Entwicklerteam tut dies bereits in einem sehr langsamen Tempo. Es gibt bereits über 60 Klassen im WordPress-System.

6
Xeoncross

Sie gehen davon aus, dass so etwas die Leistung verbessern würde. Spoiler - nein, das wird es nicht.

Der Ladevorgang in sehr losen Worten besteht aus:

  1. Optional Code ausführen, der für das Nachschlagen von Definitionen verantwortlich ist (Autoload oder benutzerdefiniert).
  2. Analysieren der Datei oder Abrufen der Ergebnisse aus dem Opcode-Cache.
  3. Zu verwendende Ergebnisse werden geladen.

Das "Autoload ist schnell" ist populärer Irrtum. Vor allem Autoload ist bequem . Es kann tatsächlich die Dinge verlangsamen in der Praxis, weil die Verarbeitung der Dateien durch den Opcode-Cache enorm verbessert wird, aber wiederholt das Auffinden dieser Dateien (Schritt 1) ​​kann nur so weit optimiert werden und summiert sich sehr schnell.

Würde der WordPress-Kern von einer besseren Organisation und dem automatischen Laden von Klassen profitieren? Dies ist jedoch nicht der Fall, da es unter der Voraussetzung entwickelt wurde, dass diese Funktion von PHP nicht verwendet wird.

Aber "Konvertieren" von Funktionen in automatisch geladene Klassen? Meiner Einschätzung nach würde dies die Leistung beeinträchtigen, während versucht wird, einen Teil des Prozesses zu optimieren, der nicht an erster Stelle steht (im aktuellen Zustand des Kerncodes/der Kernlast).

13
Rarst

funktionaler interpretierter Code ist immer schneller als OOP eins. Vergleichen Sie

function hello_mark() {
  echo 'hello mark';
}

hello_mark();

mit

class mark {
  function say_hi() {
    echo 'hello mark';
  }
}

$m = new mark();
$m->say_hi();

Ich denke, es ist offensichtlich, was schneller zu interpretieren und auszuführen ist.

Die Leute machen nicht OOP, weil es schneller ist, sie machen es, weil es die "Problemdomäne" besser darstellt und einfacher zu pflegenden Code erzeugt.

Der Code sollte so organisiert sein, dass er einfacher zu pflegen und zu entwickeln ist, damit die Geschwindigkeit immer bessere Interpreter verwenden, Code maschinell kompilieren oder wie im HipHop von Facebook die Funktionen der von Ihnen unterstützten Sprache reduzieren und integrieren kann Webserver in Ihren Dolmetscher.

Speziell für WordPress ist die Qualität des verwendeten Caches entscheidend für die Geschwindigkeit der Site. Keine Verbesserung des PHP-Codes bringt Ihnen den gleichen Leistungsschub wie die Verwendung von Objekt-Caching.

Nur weil es viele Funktionen gibt, die nicht faul geladen sind, heißt das nicht, dass sie selbst bei faulem Laden nicht geladen werden, wenn WordPress seine Initialisierung beendet. Würdigen Sie die Kernentwickler, die die Sprache gut genug kennen, um Funktionen, die für die Initialisierung nicht benötigt werden, in ihre eigenen Dateien zu packen, wenn sie die logische Struktur der Software nicht brechen (dh wenn es dumm ist, sie zu packen) update_option in einer anderen Datei als delete_option, nur weil delete_option während der Initialisierung nicht aufgerufen wird)

9
Mark Kaplun

Ich wünsche Ihnen viel Glück, aber dies wird die Leistung in keiner Weise verbessern.

WordPress wird in der Tat im Laufe der Zeit und mit zunehmenden Änderungen immer objektorientierter. Jedes Update in den letzten 4 Jahren hat ein größeres Stück Code zu einem klassenorientierteren Design umgestaltet.

Nichtsdestotrotz sind OO und Autoload und andere Dinge von Natur aus weder "schneller" noch "besser". Keine Sorge, dies ist ein weit verbreiteter Irrtum.

OOP ist im Allgemeinen eine andere Organisationsform in der Programmierung. In vielen Fällen ist dies ein vernünftigerer und sauberer Ansatz. Aber es ist nicht von Natur aus "besser" und tatsächlich in fast allen realen Szenarien merklich langsamer und speicherintensiver oder bestenfalls ausgeglichen. Das OOP -Modell wird im Allgemeinen bevorzugt, weil es a) leichter zu warten und Code zu testen ist, b) in vielen Schulen als die "richtige" Art gelehrt wird und c) Programmierer die Art von Leuten sind, die es sind bauen gerne Modelle von Dingen. OOP passt gut zu dieser "Modell" -Mentalität. Stellen Sie ein "Ding" mit einem einzigen Codestück dar und lassen Sie dann Ihre "Dinge" mit anderen "Dingen" interagieren, z. B. indem Sie Legostücke zusammenfügen. Ordentlich, sauber, ordentlich. :)

Die Wahrheit ist, dass Autoload bei Dingen wie Opcode-Caching praktisch keine Geschwindigkeitsvorteile bietet, sondern nur organisatorische. Und versteh mich nicht falsch, ein Vorteil ist ein Vorteil und eine bessere Organisation ist eine gute Sache. Aber Sie erhalten eine bessere Organisation durch die Organisation von Dingen, nicht durch automatisierte Prozesse.

Können Sie Code schreiben, um den gesamten Code in Klassen zu verschieben und die Funktionen dann zu Hooks in diesen Klassen zu machen? Sicher wahrscheinlich. Was hilft es? Nichts von Substanz.

Um auf Ihre speziellen Wünsche einzugehen:

Es ist viel schwieriger, Funktionen abzuschreiben. Daher beginnt diese Frage mit dem ersten Umschreiben des Systems.

Erstens, ich denke, Sie meinten "veralten".

Zweitens können Sie nicht alles auf einmal umschreiben und Ihre Ziele erreichen. Das ist meine ganze Sache. Gehen Sie zurück und schauen Sie sich 3.1 oder 3.2 an. Schauen Sie sich nun 4.0 an. Notieren Sie die Anzahl der Klassen und die Art und Weise, wie sie im Laufe der Zeit tatsächlich überarbeitet werden.

Es macht keinen Sinn, einige Zeit damit zu verbringen, Arbeitscode umzuschreiben, um am Ende die gleichen Ergebnisse zu erzielen, es sei denn, Sie werden ihn tatsächlich verbessern. Wenn jedes Teil in WordPress verbessert wird, wird es normalerweise in ein Klassen-/OOP-System umgewandelt. Allmähliche Evolution. Ändern Sie sich im Laufe der Zeit, damit alte Plugins absterben und neuer Code erstellt werden kann, um dies zu unterstützen und Fehler zu beheben. Sie können die Welt nicht über Nacht durchbrechen und erwarten, dass alle mitmachen. Sie müssen die Dinge langsam und methodisch ändern.

7
Otto

@Xeoncross,

Sie schreiben in Ihr WP Dev-Profil

Möglicherweise stellen Sie fest, dass einige meiner Fragen sehr tief im Herzen bestimmter Probleme liegen, da ich mich um die höchstmögliche Optimierung bemühe, die in meinen Apps möglich ist.

Das ist alles in Ordnung und gut für eine App, Ihre App oder eine App, an der Sie arbeiten. oder Ihre eigene Programmierphilosophie und -techniken.

Aber Wordpress ist eine Community und funktioniert als solche anders. Es kann (aus Mangel an einem besseren Wort) Dinge in Bezug auf Programmierstrukturen, Sprachen und Effizienz opfern, die bei kleinen oder einzelnen Projekten Priorität haben.

Aber Wordpress gewinnt viel, weil es eine Community ist. Das Ökosystem ist groß und vielfältig, die Entwicklung schreitet voran und WordPress erfreut sich - oder trotz allem - großer Beliebtheit.

Als Community kann Wordpress nicht so funktionieren wie ein einzelnes Projekt oder ein Entwickler.

Sie vergleichen Äpfel und Orangen sowie die Bäume, auf denen sie wachsen, und die Menschen, die Äpfel besser mögen als Orangen.

Ich betrachte mich nicht als Programmierer, und ich kann nicht die Vorteile und Verdienste von OOP, Klassen, Prozeduren und so weiter und so fort argumentieren.

1
markratledge