Guter Punkt. Wozu Beiträge per SQL in den Speicher holen, die gerade nicht gebraucht werden. Eventuell verbessert dass das Problem bei truser? Kanns nicht bewerten, ich hab nirgends ein derartig grosses Forum zum testen.IMC hat geschrieben: 16.08.2025 18:14 2. Die Datenbankabfrage der Beiträge soweit geändert, dass nur die für die Seitenanzeige benötigten Beiträge geladen werden.
Ja das ist das Problem wenn man nicht direkt mit ähnlichem Umfang testen kann. Ich kenne das Problem von WWH, da hatte ich vor vielen Jahren auch eine grössere Aktion um die Leistung zu verbessern und Laufzeiten zu optimieren, da war ich direkt auf den Melder angewiesen, der dann die Updates getestet und Rückmeldungen geben musste.In meinen Testforum konnte ich durch dies Änderung aber keine schnellere Ladezeit des Forums feststellen.
Hmm wir haben bei RTNG eigentlich keine Stellen bei denen die Art der Schleifenbildung relevant für die Laufzeit wäre, oder? Wir haben bei RTNG eher Optimierungspotential seitens SQL?An einigen Stellen könnte man Schleifen durcharray_map()
ersetzen. Dies würde den Code vielleicht ewas übersichtlicher machen aber auch verlangsamen. Deshalb habe ich davon abgesehen.
Aber so Vergleiche kannst du am besten mit
microtime()
oder hrtime()
testen, wenn die Auflösung des ersteren nicht reichen sollte. Das verwende ich auch gezielt um Laufzeiten zu optimieren. Zum Beispiel bei einer Anfrage auf .com war das ein Teil meiner Antwort:Re: use php to add extra css class to existing class
Wegen dev, da sind veraltete Daten:
https://github.com/IMC-GER/RecentTopics ... poser.json
Version und Datum sind noch älter als 1.0.0 Release und können deshalb im dev Branch nicht stimmen.