anpera.net

Zweifelsohne stimmt folgendes:

LOTGD macht Spass
LOTGD reizt den Server meist voll aus

Was auch stimmt ist

Der Code von LOTGD ist teilweise ganz schön konfus und vor allem
Der Code ist teilweise unperformant

Viel ändern kann man daran nicht, wenn man nicht das ganze Spiel neu programmieren möchte. ABER man kann bei der Entwicklung von Specials/Addons/Mods darauf achten so optimal wie möglich zu programmieren, selbst die Leute die noch nicht viel PHP können.

Meine Vorschläge
Quotierung/Die Anführungszeichen:
PHP Unterscheidet die "Doublequotas" und die 'Singlequotas', aber worin besteht der unterschied? PHP parsed alle Texte, die in "Doublequotas" stehen noch einmal durch, ob darin eine Variable/Escapezeichen vorkommt, die es ersetzen muss, so wird zum beispiel aus "Hallo $session[user][name]" ein Hallo Dragonslayer und 'Hallo $session[user][name]' bleibt einfach so wie es ist. Das bedeutet natürlich, dass die Bearbeitung von 'Singelquotas' schneller von statten geht als die von "Doublequotas".
Mein Vorschlag: Wenn in einem Text keine Variable ersetzt werden soll, dann verwendet 'Singlequotas' zum Beispiel if($_GET['op']='') anstelle von if($_GET['op']="").
Man mag einwenden, dass sich das doch nur wenig auswirkt...ja, aber nachdem ich die common.php mal konsequent überarbeitet hatte lud plötzlich jede Seite 0,1 Sekunden schneller und die Serverlast sank um 10%...

Quotierung in arrays
Natürlich kann man stets $session[user][name] schreiben und php weiß was gemeint ist. ABER, es denkt bei der Bearbeitung zunächst "Hey, name und user-sind das Konstatnten? Muss ich die ersetzen? mal gucken? Nein, kenne ich nicht, müssen wohl texte sein, teste ich mal texte...ja, so klappt es..."
Das dauert lange! Nutzt also am besten immer 'SingleQuotas' wenn ihr die Arrayindizes abfragt, also $session['user']['name']

If gegen switch
Bei einem Waldspecial habe ich manchmal sehr viele verschiedene Verzweigungsmöglichkeiten, die meistens über if Abfragen realisiert werden
Es ist jedoch so, dass zwei
if($_GET['op']=='x'){}
if($_GET['op']=='y'){}
merklich langsamer sind als ein
switch ($_GET['op'])
{
case 'x':...
case 'y':...
}
Warum das so ist weiß ich nicht,aber die Zend engine,die php Skripte ja parsed arbeitet eben so.

Funktionsaufrufe
Funktionen sind etwas tolles, ohne Frage, aber jeder Funktionsaufruf bedeutet auch Overhead, also Belastung des Servers, es gilt also unnötige Aufrufe zu vermeiden.
Besonders deutlich bei LOTGD ist dies bei der function output(), die ja viel parsen/suchen und ersetzen muss.
Es ist demzufolge viel langsamer
output('hallo'); output('Das');output('ist');output('ein');output('test'); zu schreiben, als
output('Hallo 'n das 'n ist 'n ein 'n test'); was den gleichen effekt hätte, aber eben 4x schneller ist.

Was sagt Ihr dazu?

_________________
Atrahor.de
http://www.atrahor.de/ci_images.php?id=1

Naja... im Prinzip hast Du recht, aber ein Unterschied von 0,1 Sekunden bzw. 10% Geschwindigkeit ist definitiv nicht dem Unterschied bei den Anführungszeichen anzulasten. Ich hab da schon viele Tests gemacht und es sind auch Unterschiede da, aber für so einen Unterschied bräuchte es doch einige Millionen simultane Seitenaufrufe - wobei dann der Server sowieso aufgrund der Anzahl der Zugriffe schon weg wäre.
Selbes gilt für die Anführungszeichen bei Arrays, die Geschwindigkeit erhöht sich, aber nur minimal. Hier ist viel wichtiger, daß der Code dadurch sauber wird und damit mögliche Probleme vermieden werden.

Die letzten beiden Punkte, die Du anführst, machen sich hingegen natürlich recht stark bemerkbar.

Allerdings solltest Du bedenken, daß die PHP-Ausführungszeit auf einem halbwegs brauchbaren Server im Vergleich zur MySQL-Zeit minimal ist - MySQL ist der Flaschenhals. Wenn das bei Dir nicht der Fall ist, d.h. PHP deutlich ausbremst, hat der Server irgendein Problem, nicht LoGD.
Daher finde ich die Vorschläge prima, aber weniger zur Beschleunigung als vielmehr, um endlich sauberen Code zu bekommen.

_________________
A bus station is where busses stop. A train station is where trains stop. On my desk there is a workstation...

naja..
Die rechner sind mittlerweile so schnell, dass man solche Dinge eigentlich schlicht und ergreifend vergessen kann.

Das mit dem Output()...

Macht's doch einfach so:

$ausgabe='Hallo';
$ausgabe.='Welt`n';
$ausgabe.='Wie ';
$ausgabe.='geht es dir?';
output($ausgabe);

--> selbst unsere houses.php mit mehr als 160kb source-code läuft sackeschnell.
YarC liest bei jedem Klick erstmal ein RIESEN array ein.. und hat Seitenaufbauzeiten von 0,05s.

_________________
http://www.plueschdrache.de 0.97
## "Of course it does not work, but look how fast it is!" ##

Was noch hilfreich wäre, wenn man die HTML codes nicht parst, sprich in etwa so schreibt:


$htmlcode = <<<HTML
dein htmlcode etc.
HTML;

echo $htmlcode;


Ich hoffe ich liege damit jetzt nicht falsch, denn so parst er nicht den inhalt das spart an machen stellen auch schon einiges

Dann wird soweit ich weiß der HTML Code immer ganz oben auf der Seite angezeigt.
Ich glaube garnicht. weil die <html> Tags erst später kommen.
Mir ist aufgefallen das in vielen Dateien zuviel aus der Datenbank abgefragt wird. zb. am Ende der Charstats();
Aja Kevz hat mir auchmal etwas von Querrychaching erzählt.
Das einzige was ich gefunden habe sind Änderungen an der my.conf Datei.
Er meinte aber die neue Version würde das auch machen.

Ist so nicht richtig.
Das ist nichts anderes als $htmlcode = "dein htmlcode etc."; - also gerade die schlechteste Möglichkeit. Variablen werden auch innerhalb dieses Blocks geparst. Der einzige Unterschied ist, daß man Anführungszeichen nicht maskieren muß.
Sinnvoll ist es daher nur dort, wo größere Strings vorkommen und dadurch die Übersicht erhöht wird.
Im neuen Hausmeisterscript ist auch so ein Teil - dort ist er genau genommen eigentlich unnötig, da es auch einfache Anführungszeichen getan hätten. Ich habe es nur der Übersicht halber genutzt, da man so besser Anfang und Ende erkennt.

Der Code wird allerdings dort angezeigt, wo er (hier per echo) ausgegeben wird und keineswegs am Seitenanfang.

_________________
A bus station is where busses stop. A train station is where trains stop. On my desk there is a workstation...

hmm ok dann muss ich mir das nochmal ankucken..

Siehe auch hier.

_________________
A bus station is where busses stop. A train station is where trains stop. On my desk there is a workstation...

Klar, ihr habt recht, eine der genannten Optionen macht natürlich das ganze noch nicht schnell und der Flaschenhals ist natürlich SQL, aber von Anperas Standard Version ausgehend sind alle Queries bereits optimal, da gibts nichts mehr zu beanstanden (ich hab stundenlang versucht die noch weiter zu verbessern ;-)). Also muss irgendwo anders gespart werden. Zum Beispiel tinyint verwenden anstelle von int, char anstelle von varchar, überflüssige indizes herausnehmen...vielleicht habt ihr ja selbst mal Optimierungsarbeit getan die man mal zusammentragten kann.

1. Punkt, und meiner Meinung nach beinahe schon das beste was man machen kann wenn man root Zugriff auf den Server hat: eacellerator bytecache installieren

2. Punkt überall wo in der DB nur ein binärer wert also true oder false gespeichert werden soll sollte wenigstens unsigned tinyint stehen anstelle int. Kleinvieh macht auch Mist. Damit spare ich mir zwar nicht die Zeit die es braucht um die Daten von der Platte zu laden, aber ich geb MYSQL mehr Platz im Speicher den es dann für wichtigere Dinge benutzen kann.

3. größerer Server ;-)
Der einzige Nacvhteil an meinem Server momentan ist, dass er nur 256 MB RAM hat...der Prozzi ist schnell genug, aber mein nächster Server wird 2GB haben! Dann passt wenigstens alles in den RAM und die Platte liegt beinahe still und das ist wohl der größte performance schub

_________________
Atrahor.de
http://www.atrahor.de/ci_images.php?id=1

Zu 1.: Bei älteren PHP-Versionen auf jeden Fall brauchbar, mit 4.3.11 aber problematisch, weil nicht dafür ausgelegt und verbugt (Probleme bei neuem Tag).
Zu 2.: Besser enum, da das binär gespeichert wird und dadurch noch kleiner ist. char statt varchar ist nur bei sehr kleinen Längen oder bei konstant feststehender Länge (z.b. immer exakt 10 Zeichen) sinnvoll, in jedem anderen Fall ein Nachteil gegenüber varchar.

Übrigens hilft es mit Abstand am meisten, die accounts-Tabelle aufzusplitten. In meinem Fall habe ich in der "alten" accounts nur noch Daten, auf die häufig von Dritten zugegriffen werden muß (sowas wie Name etc). Andere Dinge (E-Mail, Passwort, übrige WK, übrige PVP etc. pp.) sind in einer anderen Tabelle. Das bringt mit Abstand am meisten, weil die große Tabelle am stärksten ausbremst.

_________________
A bus station is where busses stop. A train station is where trains stop. On my desk there is a workstation...

Ich muss einfach mal diesen uralt Thread von mir rauskramen und einen Link posten der vielen bestimmt die Augen groß werden lässt:

http://benchmark.nophia.de/benchmarks.html

Für die, die sie nicht kennen: Auf dieser Seite sind viele Benchmarks von alltäglichen Programmierregeln und Unarten zusammengefasst und übersichtlich in tabellarischer Form angegeben was denn nun am langsamsten und was am schnellsten ist.

Zugegeben, vieles ist einfach nur experimenteller Natur, aber besonders
die Benchmarks zum Thema Single oder Double Quota, Kontrollstrukturen und Dateihandling prügle ich meinen Proggern ins Hirn!

Und jetzt Hand aufs Herz, wer von Euch benutzt bei keiner der genannten Varianten nicht wenigstens einmal die schlechteste Variante ;-)
Na? Double Quotes vielleicht? Oder dieses beknackte while (list($key,$var) = each...)? vielleicht sogar ständiger Aufruf von output() ?

Ich höre in diesem Zusammenhang ständig sowas wie: "Ach, die Millisekunde machts doch jetzt nicht" - OH DOCH das läppert sich übel zusammen, glaubt es mir!

Achja, mein größter Hass im LOTGD Code ist übrigens die Funktion Appoencode...da kann man dran basteln wie man will, die wird immer lahm bleiben. Aber wer in seinen Files 40x output() aufruft ist selbst schuld ;-)

Sodele, viel Spass beim lesen und optimieren des eigenen Codes

_________________
Atrahor.de
http://www.atrahor.de/ci_images.php?id=1

Mh. Vieles davon war mir klar.
Aber nach dem Benchmark sind doublequotes gar nicht so übel. Im Gegenteil. Zusammengesetzte Doublequotes sind sogar noch schneller als Singlequotes oder Doublequotes im Stil von "blah $var blah". Aber dass "HERE-DOC (und echo für Variablen)" sogar noch schneller als Singlequotes sind?

Sowohl mit als auch ohne Variablen. Na? *sfg*

Dass das while, list, each Konstrukt langsamer ist verblüfft mich allerdings. Bei meinen Tests wars schneller als foreach O.O

Appoencode... Naja. Mal sehn. Vielleicht geh ich da nochmal über die Bücher *g*