nicht angemeldet
seth
Gunnar Bittersmann
dedlfix
Tobias Kloth
Der Martin
Der Martin
Hallo,
wie kann ich PHP Code schreiben der wirklich sehr effektiv ist und in null komma ganz wenig zeit durchrattert?
Klar ich könnte für jeden Ausdruck einen eigenen Benchmarktest machen.
Was ich brauche ist sowas wie zum Beispiel folgender Code:
echo "Hallo ich bin ein see...hhhr laaaanger String.";
// Das ist wesentlich schneller
echo 'Hallo ich bin ebenfalls ein ssee...hhr. laaanger String.';
// Die Begründung ist hier die unterschiedliche interpretation des Interpreters
// oder:
$var = 5000 / 2;
// schneller
$var = 5000 * 0.5;
Sowas in der Art bräuchte ich für so ziemlich alles was man in PHP schreiben kann nicht nur obiges.
Als Hinweis ist zu sagen das ich ein bestehendes Projekt so weit wie irgendwie möglich optimieren soll.
ich
Und jetzt soll sich einer die Zeit nehmen und dir ca. 1 milliarden Möglichkeiten aufzählen?(es gibt sicherlich noch unendlich mehr :))
Wenn es sich nur um einzelne Berechnungen handelt und du nicht etliche tausend stück davon hintereinander durchführst (das gleiche gilt bei den Strings) ist der Unterschied sowieso zu vernachlässigen.
Und jetzt soll sich einer die Zeit nehmen und dir ca. 1 milliarden Möglichkeiten aufzählen?(es gibt sicherlich noch unendlich mehr :))
mach mal ;)
OK, werde dann wohl selber ein paar benchmark messungen durchführen ...
Und jetzt soll sich einer die Zeit nehmen und dir ca. 1 milliarden Möglichkeiten aufzählen?(es gibt sicherlich noch unendlich mehr :))
mach mal ;)
Ich fange mal damit an. Wenn ich fertig bin, stelle ich meine Ergebnisse online. Wir sehen uns in ein paar Jahren :)
Hello,
Ich fange mal damit an. Wenn ich fertig bin, stelle ich meine Ergebnisse online. Wir sehen uns in ein paar Jahren :)
Wieso, willst Du soooo inperformante Statements verwenden?
*scnr*
Harzliche Grüße vom Berg
http://www.annerschbarrich.de
Tom
Wieso, willst Du soooo inperformante Statements verwenden?
Es ging ja darum alle Möglichkeiten aufzuzeigen, wie man bestimmte Vorgänge perfomanter machen kann. Es gibt unzählige Möglichkeiten, weil es immer darauf ankommt, wo und wie man sie nutzt. Ich wollte damit nur sagen, dass keiner hier sagen kann, wie du deinen Code performanter gestallten kannst, weil keiner deinen Code kennt. Und _alle_ Möglichkeiten aufzuzeigen, in welcher Situation man welche Variante nutzen sollte, dauert nunmal ewig :)
Hello,
[...]
Das hatte ich schon verstanden.
Ich erinnere mich aber noch gut an die Zeit, als wir die Zyklus-Anzahl bei Assembler-Routinen ausgezählt haben, um festzustellen, welche tricky Version die schnellste ist.
Bei PHP würde mich generell erstmal interessieren, ob OOP (ab Vers. 5) langsamer ist, als eine prozedurale Lösung.
Harzliche Grüße vom Berg
http://www.annerschbarrich.de
Tom
ihr habt ja von Strings und Arrays geredet.
Was ist eurer Meinung nach schneller, lesbarkeit ist ja ähnlich.
Soll man einen String zuerst in ein Array packen und dann mit foreach durchlaufen oder for und die gschweiften klammern verwenden.
Ich habe einige Stringoperationen die so durchgeführt werden aber momentan noch in der ersten Variante
ich
ihr habt ja von Strings und Arrays geredet.
Was ist eurer Meinung nach schneller, lesbarkeit ist ja ähnlich.
Soll man einen String zuerst in ein Array
Versteh ich Dich richtig dass Du damit ein Array von Zeichen meinst ?
packen und dann mit foreach durchlaufen oder for und die gschweiften klammern verwenden.
Falls ja, dann müsste das auf das gleiche hinauslaufen, sofern Du die Stringlänge einmal vor der Schleife bestimmst und nicht bei jedem Durchlauf neu im Schleifenkopf.
Sind beides einfache Iteratoren; nur einmal halt implizit.
Die Dereferenzierung zu dem Zeichen wirst Du in dem "{}" ja wahrscheinlich eh brauchen, oder ?
So ist das imo algorithmisch einzuschätzen; ob der Interpreter irgendeine sonstige "Magic" hat weiss ich nicht; würde mich aber wundern.
Am besten Du überprüfst das mit einem kleinen Test.
Grüsse
hkl
Ich habe einige Stringoperationen die so durchgeführt werden aber momentan noch in der ersten Variante
ich
Moin!
ihr habt ja von Strings und Arrays geredet.
Was ist eurer Meinung nach schneller, lesbarkeit ist ja ähnlich.
Strings sind Zeichenketten. Arrays sind Datenstrukturen. Das sind zwei komplett unterschiedliche Dinge, die man nicht vergleichen kann.
Und außerdem geht es nicht um "Meinungen" darüber, was schneller ist, sondern um "Messungen".
Was du nicht messen kannst, kannst du nicht optimieren.
Soll man einen String zuerst in ein Array packen und dann mit foreach durchlaufen oder for und die gschweiften klammern verwenden.
Das hängt vollkommen davon ab, welche Aufgabe zu erfüllen ist.
- Sven Rautenberg
Moin!
ihr habt ja von Strings und Arrays geredet.
Was ist eurer Meinung nach schneller, lesbarkeit ist ja ähnlich.
Strings sind Zeichenketten. Arrays sind Datenstrukturen.
Das sind zwei komplett unterschiedliche Dinge, die man nicht vergleichen kann.
Zeichenketten lassen sich aber als Arrays ( oder Vektoren ) von Zeichen interpretieren und traversieren.
Und außerdem geht es nicht um "Meinungen" darüber, was schneller ist, sondern um "Messungen".
Und um Algorithmik.
[...]
Grüsse
hkl
Hello,
einen String (den man als Array nutzt) zu durchlaufen, geht schneller, als ein PHP-Array zu durchlaufen, das die gleichen Werte enthält.
Wir hatten hier neulich den Fall eines "Array of Byte" oder alternativ eben eines Strings.
Ich habe es ausprobiert und die Stringverarbeitung war ca. drei bis viermal schneller.
Das bezieht sich jetzt aber auf ein "unsortiertes PHP-Array". Wenn man die Möglichkeiten von "balanced trees" ausnutzt, wird bei genügend großer Datenmenge das "Array" gewinnen.
Harzliche Grüße vom Berg
http://www.annerschbarrich.de
Tom
Hello,
einen String (den man als Array nutzt) zu durchlaufen, geht schneller, als ein PHP-Array zu durchlaufen, das die gleichen Werte enthält.
Das mess ich deutlich anders.
Wenn ich mit einem Array arbeite dass den String bereits enthält(!)
und einem String dessen Länge bereits ermittelt wurde ist das Array ziemlich konstant 10% schneller _durchlaufen_.
Das mag allerdings bei unterschiedlichen Speicherzuständen unterschiedlich ausfallen.
Wenn man die Zeit zur Konvertierung _von_ einem String in ein Array
( mittles str_split() ) miteinrechnet stimmen Deine Zahlen.
Allerdings stellt sich die Frage ab wann diese Konvertierung dennoch rentiert wenn man das Array mehrfach durchläuft.
Das kann gerade bei sehr grossen Strings naturgemäss öfters Sinn machen.
Stringlänge 26 - 2.600.000 Characters
PHP 5.2.1 CLI unter Windows XP SP 2
Grüsse
hkl
Hello,
Das mess ich deutlich anders.
Wenn ich mit einem Array arbeite dass den String bereits enthält(!)
Wie leigt denn cer String in dem Array? Jedes Zeichen in einem anderen Element?
Wir sprechen auch beide von PHP?
und einem String dessen Länge bereits ermittelt wurde ist das Array ziemlich konstant 10% schneller _durchlaufen_.
Du meinst den sequenziellen Zugriff? Zeichen für zeichen der Reihe nach?
Also im gegenpart zum wahlfreien Zugriff?
Wenn man die Zeit zur Konvertierung _von_ einem String in ein Array
( mittles str_split() ) miteinrechnet stimmen Deine Zahlen.
Nö sowas meinte ich nicht.
Zur Messung gehören natürlich nicht nur das sequenzielle Durchlaufen, sondern auch random Access und Kopieraktionen.
Allerdings stellt sich die Frage ab wann diese Konvertierung dennoch rentiert wenn man das Array mehrfach durchläuft.
Das kann gerade bei sehr grossen Strings naturgemäss öfters Sinn machen.
Und was ist mit rückwärts?
Nur als Zusatzfrage:
Und wie sieht es mit dem Speicherverbrauch aus?
Harzliche Grüße vom Berg
http://www.annerschbarrich.de
Tom
Hello,
Das mess ich deutlich anders.
Wenn ich mit einem Array arbeite dass den String bereits enthält(!)
Wie leigt denn cer String in dem Array? Jedes Zeichen in einem anderen Element?
Ja, das hab ich mit str_split() gemacht; siehe unten.
Nicht mit array($str)... ;-)
Wir sprechen auch beide von PHP?
;-)
Siehe meine Daten zur Testumgebung.
und einem String dessen Länge bereits ermittelt wurde ist das Array ziemlich konstant 10% schneller _durchlaufen_.
Du meinst den sequenziellen Zugriff? Zeichen für zeichen der Reihe nach?
Also im gegenpart zum wahlfreien Zugriff?
Ja, das hat mich auch mehr als überrascht.
Über den Grund kann ich auch nur raetseln.
Billiger als ein mit O=const zu errechnendes Displacement kann ein Tree wohl kaum sein. Ich vermute dass es an der Allokation liegt.
Wenn man die Zeit zur Konvertierung _von_ einem String in ein Array
( mittles str_split() ) miteinrechnet stimmen Deine Zahlen.Nö sowas meinte ich nicht.
Zur Messung gehören natürlich nicht nur das sequenzielle Durchlaufen, sondern auch random Access und Kopieraktionen.
Hier ging's um den Vergleich mit foreach.
Das entspricht der Funktion eines einfachen Forward-Iterators.
Allerdings stellt sich die Frage ab wann diese Konvertierung dennoch rentiert wenn man das Array mehrfach durchläuft.
Das kann gerade bei sehr grossen Strings naturgemäss öfters Sinn machen.Und was ist mit rückwärts?
Kann ausser Ansatz bleiben, siehe vor. Abschnitt.
Nur als Zusatzfrage:
Und wie sieht es mit dem Speicherverbrauch aus?
Der ist zumindest grösser, genaue Zahlen wird der/die FragestellerIn wohl sowieeo selbst ermitteln ( müssen),
Harzliche Grüße vom Berg
http://www.annerschbarrich.deTom
Grüssse
hkl
Hello,
es wird Zeit, dass ich mal wieder intensiv-Studium betreibe und hineingucke in den Quellcode von PHP...
Manches ist wirklich schon so verknotet, dass man es nicht ahnen kann. Die Geschichte mit den File-Buffers ist doch ähnlich komplex. Im Einzelbetrieb schnell, im konkurrierenden Betrieb plötzlich hinderlich.
Harzliche Grüße vom Berg
http://www.annerschbarrich.de
Tom
These :
Die grossen Strings bau ich natuerlich durch Konkatenierung zusammen.
Er indiziert wahscheinlich die Teilbaüme nicht um
Beim str_split() ins array macht er das hingegen erzwungenermassen.
Hältst Du das für plausibel ?
Grüsse
Holger
P.S.: Wo klemmt's denn bei den Buffern?
Auch reiner Lesezugriff durch Mutex/Semaphore/Teufelwasauchimmer blockiert?
Hello,
These :
Die grossen Strings bau ich natuerlich durch Konkatenierung zusammen.
Er indiziert wahscheinlich die Teilbaüme nicht um
Klar, wenn ein "String" größer als ein Segment wird, muss er vermutlich sowieso zusammengesetzt werden, oder wird bei x366 immer über die klassischen Segmentgrenzen hinweg gearbeitet?
Ich weiß nicht mehr, wie das im Protected Mode funktioniert mit very large objects.
Der Einsprungspunkt wird durch den Descriptor für ein Datensegment bestimmt. Der zeigt ja eigentlich auf einen 32-Bit-Wert. Direkt kommt man an den ja gar nicht dran. Und das Dereferenz-Register hat im Prinzip ja auch 32 Bit...
P.S.: Wo klemmt's denn bei den Buffern?
Auch reiner Lesezugriff durch Mutex/Semaphore/Teufelwasauchimmer blockiert?
Ich habe das noch nicht genauer untersucht.
http://www.php.net/manual/en/function.stream-set-write-buffer.php
Harzliche Grüße vom Berg
http://www.annerschbarrich.de
Tom
Hello,
These :
Die grossen Strings bau ich natuerlich durch Konkatenierung zusammen.
Er indiziert wahscheinlich die Teilbaüme nicht umKlar, wenn ein "String" größer als ein Segment wird, muss er vermutlich sowieso zusammengesetzt werden, oder wird bei x366 immer über die klassischen Segmentgrenzen hinweg gearbeitet?
Ich weiß nicht mehr, wie das im Protected Mode funktioniert mit very large objects.
Die Segmentdeskriptoren haben eine 32-Bit Startadresse
und ein 20-Bit Limit.
Wenn uudem das Granularitätsbit (DW #2 / Bit #23 = Bit #54) gesetzt ist, eine Granularität von 4K ( statt 1 Byte )
4K = 2^12
2^12*2^20 = 2^32 - wie es sein soll ;-)
Aber das Paging ist wohl eher das Problem
32 Bit Basisadresse in CR3
Lneare Adresse :
Pageverzeichnis# (10Bit)
Tabelle# (10Bit)
Offset (12Bit)
( Die Einträge im Verzeichnis sind selbst 32Bit lang, in der Tabelle auch, aber von letzterem sind nur Bit #12 - Bit #31 nutzbar; Bit #0 ist das "Present Bit" das der Proz zum Page Faulting, also das OS zum Swapping braucht. )
Aber der Offset halt nur 2^12 = 4k = Pagesize des x386.
Allerdings können natürlich mehrere aufeinanderforlgende Pages durch aufeinanderfolgende Einträge inder Pagetabelle in einen logischen Block fallen.
Wobei mir gerade mal ganz peinsam einfällt ob NT dass ich nicht weiss ob NT eigentlich _immer_ Paging nutzt.
Ich glaub aber schon dass das so ist.
Technisch zwingend ist das ja aber nicht - der Mechanismus von PageFaulting / Exception / Handler kann auch ( wie z.B. auf nem Alpha ) nachgebildet werden.
Aber wenn Du mal wieder im PHP Quellcode arbeitest
;-) ;-) ;-)
unsigned long _cr0;
_asm {
push eax
/* _THIS_ way shouldn't cause an exception */
mov eax,cr0
/* _THIS_ on the other hand
mov cr0, eax
is an isuue Bootstraps ;-) */
push eax
pop _cr0
pop eax
}
// ;-)
Bit #31 ist "Paging Enabled".
Aber ich glaub schon das das nach dem Boot immer gestzt ist; im TSS ist CR0 gar nicht enthalten.
Das ist so das was ich zum Speichermodell des Wintel x386 zusammenkriege.
Grüsse
Holger
Der Einsprungspunkt wird durch den Descriptor für ein Datensegment bestimmt. Der zeigt ja eigentlich auf einen 32-Bit-Wert. Direkt kommt man an den ja gar nicht dran. Und das Dereferenz-Register hat im Prinzip ja auch 32 Bit...
P.S.: Wo klemmt's denn bei den Buffern?
Auch reiner Lesezugriff durch Mutex/Semaphore/Teufelwasauchimmer blockiert?Ich habe das noch nicht genauer untersucht.
http://www.php.net/manual/en/function.stream-set-write-buffer.phpHarzliche Grüße vom Berg
http://www.annerschbarrich.deTom
Wieso, willst Du soooo inperformante Statements verwenden?
Es ging ja darum alle Möglichkeiten aufzuzeigen, wie man bestimmte Vorgänge perfomanter machen kann. Es gibt unzählige Möglichkeiten, weil es immer darauf ankommt, wo und wie man sie nutzt.
Ein Mathematiker, ein Physiker und ein Ingenieur fahren mit dem Zug durch die Lüneburger Heide.
( Sie sitzen in einem Abteil. )
Ingenieur, aus dem Fenster deutend, : "Schaut mal da, es gibt hier Schwarze Schafe!"
Physiker : "Na, ja... es gibt hier zumindest _ein_ schwarzes Schaf"
Mathematiker "Es gab draussen eben etwas das aussah wie ein Schaf und das gerade eben auf mindestens einer Körperhälfte schwarz gefärbt schien."
=> Wer ist denn Deiner Meinung nach jetzt der Intelligentere?<=
Grüsse
hkl
Hello,
vielleicht ist 'was dabei http://www.opensourcetesting.org/performance.php
Harzliche Grüße vom Berg
http://www.annerschbarrich.de
Tom
Hallo ich.
wie kann ich PHP Code schreiben der wirklich sehr effektiv ist und in null komma ganz wenig zeit durchrattert?
Entwickle ein Gespür dafür, was schnell und was langsam ist. Versuche, auch wenn es merkwürdig klingen mag, in den Parser hinein zu versetzen; was kann er direkt und damit schnell verarbeiten und wie kann man kritische Stellen aufdröseln, um sie ihm schmackhafter zu machen. Ich weiß nicht, ob man dies erlernen kann, aber ich für meinen Teil arbeite so. Ein Verständnis über die zugrunde liegende Technologie (bei PHP eben C) sowie Meinungen von Experten fließen ebenfalls in die Entscheidung ein, was denn „effizienter“ Code ist.
Klar ich könnte für jeden Ausdruck einen eigenen Benchmarktest machen.
Was ich brauche ist sowas wie zum Beispiel folgender Code:
echo "Hallo ich bin ein see...hhhr laaaanger String.";
// Das ist wesentlich schneller
echo 'Hallo ich bin ebenfalls ein ssee...hhr. laaanger String.';// Die Begründung ist hier die unterschiedliche interpretation des Interpreters
Ja, da bei zweiterem der String lediglich nach „\'“ geparst werden muss.
> ~~~php
// oder:
> $var = 5000 / 2;
> // schneller
> $var = 5000 * 0.5;
>
>
Noch schneller:
$var = 5000 >> 1;
(Bei obigem würde ich die Multiplikation lediglich als „weicher“ empfinden; ob sie schneller ist, könnte ich nicht abschätzen.)
Als Hinweis ist zu sagen das ich ein bestehendes Projekt so weit wie irgendwie möglich optimieren soll.
Du weißt aber, dass man Dinge aber auch kaputtoptimieren kann, ja? Spätestens wenn der genutzte Code nicht mehr menschenlesbar ist, sollte man überlegen, ob dies den Aufwand rechtfertigt.
Einen schönen Donnerstag noch.
Gruß, Mathias
Hello,
$var = 5000 >> 1;
Nach shr und shl habe ich die letzten Tage gesucht, und glatt nicht mehr gewusst, wie die sich in PHP nennen, um sie auch zu finden... *tztz*
Dann bin ich nacher aber drüber hinweggekommen.
Die Frage schwirrte aber eben immer noch unerledigt im Hinterkopf rum.
Dabei hätte ich ja nur unter Operatoren gucken müssen
http://www.php.net/manual/de/language.operators.bitwise.php
Ich denke, bei PHP hat man den meisten Erfolg, wenn man sich erstmal Dateioperationen, Datenbank-Verbindungen und Array-Zugriffe vornimmt. Generell sollte jede Funktion eine abgeschlossene Operation ausführen, aber das Verbinden zur Datenbank (und wieder trennen) sollte man z.B. nicht der einzelnen Funktion überlassen, sondern generell für das Script regeln. Das Gleiche gilt für das Öffnen und Schließen von Dateien. Wenn man genügend Speicher hat, kann man da auch 'was rausholen.
Harzliche Grüße vom Berg
http://www.annerschbarrich.de
Tom
Wenn man genügend Speicher hat, kann man da auch 'was rausholen.
Speicher versauen ist keine Option für Sktipte auf fernen Servern.
Zudem: Auch Speicher muss aloziert werden, und das braucht jedesmal Zeit, wenn man nicht im Voraus aloziert oder bereits gebrauchten Speicher klug wiederverwendet.
Hello,
Wenn man genügend Speicher hat, kann man da auch 'was rausholen.
Speicher versauen ist keine Option für Sktipte auf fernen Servern.
Zudem: Auch Speicher muss aloziert werden, und das braucht jedesmal Zeit, wenn man nicht im Voraus aloziert oder bereits gebrauchten Speicher klug wiederverwendet.
Genau, deshalb sagte ich ja, die Dateien nicht immer öffenen und schließen, sondern offen halten. Dafür benötigt man dann aber Speicher.
Und auch nicht jede Zeile einzeln wegschreiben, sondern einen ganzen Block.
PHP arbeitet normalerweise mit Bufferung (typisch 8k); es ist also nicht ganz so einfach, hier zu optimieren. Aber Versuch lohnt sich.
Harzliche Grüße vom Berg
http://www.annerschbarrich.de
Tom
Tach.
// oder:
$var = 5000 / 2;
// schneller
$var = 5000 * 0.5;
>
> Noch schneller:
>
> `$var = 5000 >> 1;`{:.language-php}
(Vermutlich) noch schneller: `$var = 2500;`{:.language-php}
\*SCNR\*
--
Once is a mistake, twice is jazz.
Hi Mathias,
// oder:
$var = 5000 / 2;
// schneller
$var = 5000 * 0.5;
>
> Noch schneller:
>
> `$var = 5000 >> 1;`{:.language-php}
aber auch sehr viel schwerer zu lesen, IMHO ;-)
> (Bei obigem würde ich die Multiplikation lediglich als „weicher“ empfinden; ob sie schneller ist, könnte ich nicht abschätzen.)
obiges ist nicht mal vergleichbar, denn eine Multiplikation mit 0.5 ist in PHP nicht das gleiche wie eine Division durch 2:
$ php -r 'printf("%s\n%s\n", gettype(5000 / 2), gettype(5000 \* .5));'
integer
double
öhm - allerdings steht unter <http://www.php.net/manual/en/language.operators.arithmetic.php>:
"The division operator ("/") returns a float value anytime, even if the two operands are integers (or strings that get converted to integers)."
Die lügen ja! \*scary\*
Gute Nacht,
Andreas.
gudn tach!
$ php -r 'printf("%s\n%s\n", gettype(5000 / 2), gettype(5000 * .5));'
integer
doubleöhm - allerdings steht unter http://www.php.net/manual/en/language.operators.arithmetic.php:
"The division operator ("/") returns a float value anytime, even if the two operands are integers (or strings that get converted to integers)."
Die lügen ja! *scary*
gemeint ist, dass nicht, wie z.b. in c, der nachkommaanteil abgeschnitten wird.
$ php5 -r "printf("%s\n%s\n%s\n", gettype(3/2), 3/2, 3>>1);"
double
1.5
1
prost
seth
Huhu seth,
gemeint ist, dass nicht, wie z.b. in c, der nachkommaanteil abgeschnitten wird.
$ php5 -r "printf("%s\n%s\n%s\n", gettype(3/2), 3/2, 3>>1);"
double
1.5
1
ach so. Ja, das ergibt Sinn. Danke dir!
Gruß,
Andreas.
Tach.
Als Hinweis ist zu sagen das ich ein bestehendes Projekt so weit wie irgendwie möglich optimieren soll.
Ich würde mir dafür zuerst die implementierten Algorithmen vornehmen, anstatt an so unwichtigen Krümel wie ...
// oder:
$var = 5000 / 2;
// schneller
$var = 5000 * 0.5;
... rumzubasteln. Vermutlich gibt es auch in diesem Projekt mehr als genug Stellen, die stärker bremsen als / 2 gegenüber * 0.5. Unnötig allgemein formulierte Datenbankabfragen beispielsweise (SELECT * FROM foo wenn eigentlich nur eine bestimmte Spalte oder eine feste Anzahl Datensätze abgeholt werden soll).
Hallo,
wie kann ich PHP Code schreiben der wirklich sehr effektiv ist und in null komma ganz wenig zeit durchrattert?
Bei den Mediengestaltern Nonprint gibts einen brauchbaren Thread dazu:
Nennt sich zwar guter Programmierstil, hat aber auf auch ein paar allg. und Performance-Tips.
http://www.mediengestalter.info/forum/10/guter-programmierstil-31521-1.html
gudn tach!
wie kann ich PHP Code schreiben der wirklich sehr effektiv ist und in null komma ganz wenig zeit durchrattert?
Bei den Mediengestaltern Nonprint gibts einen brauchbaren Thread dazu:
Nennt sich zwar guter Programmierstil, hat aber auf auch ein paar allg. und Performance-Tips.
http://www.mediengestalter.info/forum/10/guter-programmierstil-31521-1.html
abgesehen davon, dass die tipps da zum groessten teil in ihrer allgemeinheit fuer doof halte (teilweise habe ich sogar die gegenteilige ansicht), habe ich dort nichts zur performance finden koennen.
prost
seth
Hello out there!
wie kann ich PHP Code schreiben der wirklich sehr effektiv ist
Effektiv sollte ein Algorithmus natürlich auch sein, aber darum geht es dir gar nicht. Was du meinst, ist effizient.
und in null komma ganz wenig zeit durchrattert?
Ist nicht die Abarbeitungszeit einen PHP-Scripts vernachlässigbar gegenüber der Übertragungszeit der generierten Ausgabe zum Client und der Zeit, die der Browser zum Rendern der Seite braucht? Durch gutes HTML lässt sich da sicher weitaus mehr rausholen als durch Rumschrauben am PHP.
Dort wäre wohl vor allem das Innere von Schleifen interessant. Da lässt sich durch Verwendung von Ganzzahlarithmetik statt Gleitkommaarithmetik und wohl überlegte Zugriffe auf Arrays vielleicht was rausholen.
See ya up the road,
Gunnar
Hallo !
Ein paaar Richtlinien gibt's schon
Strings
-------
Stringverarbeitung ist immer teuer.
Möglichst keine "Bubblesorts" - werden gerne implizit benutzt:
"Wir haben 1000 Worte in einem String und durchsuchen jedes einzeln manuell nach einer bestimmten Zeichenfolge." ;-(
Sowas machen Datenbanken oder Bibliotheken meistens besser.
Wenn ein String einmal parsed wurde nicht nochmal kopieren und erneut parsen. Passiert zum Beispiel wenn man XML Daten in einem Puffer haelt und immer wieder neu in einen Parser lädt.
Wenn eine Applikation eine gute Kapselung einzelner Module aufweist kann genau die dazu führen dass Parsing ( XML-Verarbeitung oder Reguläre Ausdrücke ) mehrfach passiert.
Schleifen
---------
Welche Schleife wird am häufigsten durchlaufen?
Die sollte man zuerst optimieren.
Egal obs Datenbanken, normale Dateien oder der Ausgabestream ist:
Alles in möglichst grossen Blöcken erledigen und Verbindungen und Handles möglichst mehrfach nutzen.
Eine Datenbankverbindung würde ich immer zumindest in der Sitzung vorhalten, ob das mittlerweile bei PHP wie unter IIS/Javascript auch ein Appliaktionsobjekt gibt weiss ich nicht. Wenns das gibt am besten sogar dort, sofern dies nicht dem Sicherheitskonzept wiederspricht.
Dateien im Textmodus zu lesen wenn man's nicht zeilenweise braucht ist oft sinnlos, binär geht's oft um ein Vielfaches schneller.
Caching ist sehr schwierig zu implemntieren aber manchmal muss es sein. Aber das ist eine Sysiphus-Arbeit !
________________
Viel Erfolg !
H.
P.S.: Wenn XML dabei ein Thema ist, hätte ich noch ein paar Tricks
auf Lager.
echo $begrüßung;
wie kann ich PHP Code schreiben der wirklich sehr effektiv ist und in null komma ganz wenig zeit durchrattert?
Das ist wie mit Sauerkraut. Am besten schmeckt es, wenn man es kurz vor dem Verzehr durch ein Schnitzel austauscht.
Aber auf PHP zu verzeichten wird vermutlich für dich keine Option sein.
Als Hinweis ist zu sagen das ich ein bestehendes Projekt so weit wie irgendwie möglich optimieren soll.
Dazu muss man schon Einblick in das Projekt haben, um die Zeitfresser zu finden. Ein Profiler könnte dabei auch helfen.
echo "$verabschiedung $name";
Moin,
zu diesem Thema kann ich folgendes Buch empfehlen:
"Professionelle PHP 5-Programmierung. Entwicklerleitfaden für große Webprojekte mit PHP 5"
Verlag: Addison-Wesley, München (Februar 2006)
ISBN-10: 3827323819
Etwa ein Viertel des Buches beschäftigt sich mit dem Thema Caching und Wiederverwertung von Berechnungen.
Gruß Spider
Hallo,
wie kann ich PHP Code schreiben der wirklich sehr effektiv ist und in null komma ganz wenig zeit durchrattert?
Klar ich könnte für jeden Ausdruck einen eigenen Benchmarktest machen.
... oder dir schon vorhandene Benchmarks anschauen.
Grüße aus Nürnberg
Tobias
wie kann ich PHP Code schreiben der wirklich sehr effektiv ist und in null komma ganz wenig zeit durchrattert?
Nur ein paar kleine Anmerkungen vom King:
Hallo King^Lully!
- "sehr effektiv" gibt es nicht
- Effizienz ist nicht nur auf die so genannte Performance zu reduzieren sondern betrifft natürlich auch die Wartbarkeit (die Übersichtlichkeit), die Weiterentwicklungsfähigkeit, die Skalierbarkeit und die "Richtigkeit" (in semantischer Hinsicht) des Codes
Das ist ja alles sehr interessant, aber warum haben andere und auch ich es dann geschafft auf die Frage des/der UrheberIn zu antworten?
- Code zu schreiben, der "superschnell" ist, ist m.E.
Fehlt da vielleicht ein "nur"?
Denn sonst ist der Satz zwar vielleicht richtig aber ohne Bezug.
etwas für Spezialisten bestimmter SW-Branchen,
Mit sehr weiten Einschränkungen...
...also eigentlich nie, oder?
da kommen dann auch welche mit Assembler und
Dies "und" ist falsch. Manchmal reicht das OS-API voll und ganz.
Funktionen aus der API des Betriebssystems
- "StandardSW" generiert eher selten Performacefragen
Das ist schlichtweg unentscheidbar, da sowohl unklar ist was Du mit StandardSW als auch was Du mit "selten" meinst.
Bei der Software die ich bislang erlebt und als "Standard" bezeichnen würde gab es immer Performancefragen.
Ausserdem geht es hier ja offensichtlich um individuellen Code.
Excel und Word sind nicht in PHP geschrieben.
---
Siehe zu solcher "Weisheit" auch meinen Beitrag über Erbsen und Schafe weiter unten im Thread.
Grüsse
hkl
P.S.: Jetzt beschwer Dich bitte nicht dass ich zur Abwechslung mal Deinen Beitrag zerpflückt habe! Das ist so öde dass ich's mir gewiss nicht zur Lebensaufgabe mache.
- "sehr effektiv" gibt es nicht
- Effizienz ist nicht nur auf die so genannte Performance zu reduzieren sondern betrifft natürlich auch die Wartbarkeit (die Übersichtlichkeit), die Weiterentwicklungsfähigkeit, die Skalierbarkeit und die "Richtigkeit" (in semantischer Hinsicht) des Codes
Das ist ja alles sehr interessant, aber warum haben andere und auch ich es dann geschafft auf die Frage des/der UrheberIn zu antworten?
Wir haben es doch auch geschafft.
Den Fragesteller haben wir uns als Neuling vorgestellt, der wissen möchte wie man effizient SW entwickelt.
- Code zu schreiben, der "superschnell" ist, ist m.E.
Fehlt da vielleicht ein "nur"?
Denn sonst ist der Satz zwar vielleicht richtig aber ohne Bezug.etwas für Spezialisten bestimmter SW-Branchen,
Mit sehr weiten Einschränkungen...
...also eigentlich nie, oder?
Wir dachten an Grafiksoftware, Editoren, Tabellenkalkulation und Spiele. Für uns ist das SpezialSW. Unter "StandardSW" verstehen Wir Verwaltungsprogramme mit transaktionalem Datenzugriff (OLTP) und OLAP. Wenn man da nicht superblöd ist als Entwickler kriegt man immer akzeptable Zugriffszeiten.
da kommen dann auch welche mit Assembler und
Dies "und" ist falsch. Manchmal reicht das OS-API voll und ganz.
Funktionen aus der API des Betriebssystems
Das "und" war selbstverständlich als "und/oder" zu verstehen.
- "StandardSW" generiert eher selten Performacefragen
Das ist schlichtweg unentscheidbar, da sowohl unklar ist was Du mit StandardSW als auch was Du mit "selten" meinst.
Siehe oben.
Bei der Software die ich bislang erlebt und als "Standard" bezeichnen würde gab es immer Performancefragen.
Performancefragen gibt es natürlich, sind aber Randthemen bzw. sollten Randthemen sein. Haben schon einige Male erlebt, dass überforderte Entwickler bei Diskussionen die Performance immer wieder bettonten ud so gröbste Designfehler rechtfertigten. Grauenhaft! Wir sind da vorbelastet i.p. "Performace".
P.S.: Jetzt beschwer Dich bitte nicht dass ich zur Abwechslung mal Deinen Beitrag zerpflückt habe! Das ist so öde dass ich's mir gewiss nicht zur Lebensaufgabe mache.
Sagen Wir mal, Unser Beitrag hat sich ordentlich verteidigt, so zu sagen von selbst verteidigt.
Den Fragesteller haben wir uns als Neuling vorgestellt, der wissen möchte wie man effizient SW entwickelt.
"Als Hinweis ist zu sagen das ich ein bestehendes Projekt so weit wie irgendwie möglich optimieren soll."
*BRR* - und "Optimieren" ist natürlich "schneller machen"...
Den Fragesteller haben wir uns als Neuling vorgestellt, der wissen möchte wie man effizient SW entwickelt.
"Als Hinweis ist zu sagen das ich ein bestehendes Projekt so weit wie irgendwie möglich optimieren soll."
*BRR* - und "Optimieren" ist natürlich "schneller machen"...
Mofafahrermentalität! Ritzelwechsler und Aufbohrer!
Hach, Wir erregen Uns schon wieder.
Den Fragesteller haben wir uns als Neuling vorgestellt, der wissen möchte wie man effizient SW entwickelt.
"Als Hinweis ist zu sagen das ich ein bestehendes Projekt so weit wie irgendwie möglich optimieren soll."
*BRR* - und "Optimieren" ist natürlich "schneller machen"...
Mofafahrermentalität! Ritzelwechsler und Aufbohrer!
Hach, Wir erregen Uns schon wieder.
??????????????????????????????????????????????????????????????
??????????????????????????????????????????????????????????????
??????????????????????????????????????????????????????????????
Solche Farben würde ich auch gerne mal hören....
Gibst Du mir auch solch einen Keks?
Grüsse
hkl
Den Fragesteller haben wir uns als Neuling vorgestellt, der wissen möchte wie man effizient SW entwickelt.
"Als Hinweis ist zu sagen das ich ein bestehendes Projekt so weit wie irgendwie möglich optimieren soll."
*BRR* - und "Optimieren" ist natürlich "schneller machen"...
Mofafahrermentalität! Ritzelwechsler und Aufbohrer!
Hach, Wir erregen Uns schon wieder.??????????????????????????????????????????????????????????????
??????????????????????????????????????????????????????????????
??????????????????????????????????????????????????????????????
Einen Ironiedetektor braucht man bei Uns meist nicht, Unser Humor verzichtet tendentiell auf rein techische Elemente, allerdings ein gewisses Verständnis der Metaphorik. Zudem darf auch Verständigkeit und Empathie am Start sein.
== [...]
== Zudem darf auch [...] Empathie am Start sein.
O.K., dann schick mir bitte ( Troy || T'Pol ) && Kekse von Deinem Planetem.
Grüsse und ein schönes Wocenende
hkl
Hallo,
*BRR* - und "Optimieren" ist natürlich "schneller machen"...
oder leistungsfähiger.
Oder schlanker bei gleicher Leistungsfähigkeit.
Oder leichter bedienbar.
Oder weniger ressourcenhungrig.
Oder ...
So long,
Martin
Hi,
Wir dachten an Grafiksoftware, Editoren, Tabellenkalkulation und Spiele. Für uns ist das SpezialSW. Unter "StandardSW" verstehen Wir Verwaltungsprogramme mit transaktionalem Datenzugriff (OLTP) und OLAP.
ich sehe das eher schon umgekehrt.
Standardsoftware ist Software, die ich im Laden kaufen kann - also zum Beispiel Grafiksoftware, Editoren, Tabellenkalkulation und Spiele. ;-)
Spezialsoftware ist dagegen Software, die individuell auf die Bedürfnisse *eines* Kunden oder eines sehr kleinen Kundenkreises zugeschnitten ist, zum Beispiel eine Steuerung für eine Industrieanlage, eine Visualisierung im Stellwerk eines Rangierbahnhofs oder ein professionelles CAD-System.
- "StandardSW" generiert eher selten Performacefragen
Ich weiß nicht, wie du das meinst - aber meine Erfahrung ist, dass Standardsoftware selten auf optimale Performance ausgelegt ist. Das würde sie für die Masse unbezahlbar machen.
Ciao,
Martin
Wir dachten an Grafiksoftware, Editoren, Tabellenkalkulation und Spiele. Für uns ist das SpezialSW. Unter "StandardSW" verstehen Wir Verwaltungsprogramme mit transaktionalem Datenzugriff (OLTP) und OLAP.
ich sehe das eher schon umgekehrt.
Zusammen wären wir ein gutes Team, schon klar. Andere Tätigkeitsschwerpunkte, die sich perfekt ergänzen.
Be my Bitch! :)
- "StandardSW" generiert eher selten Performacefragen
Ich weiß nicht, wie du das meinst - aber meine Erfahrung ist, dass Standardsoftware selten auf optimale Performance ausgelegt ist. Das würde sie für die Masse unbezahlbar machen.
Für mich ist "StandardSW" RDBMS-basierte Verwaltungssoftware, die meines Erachtens im Prinzip jede Firma braucht. Diese ist in der Tat kundenspezifisch. Und auch da ist Performance untergeordnet und sollte eigentlich nicht diskutiert werden müssen (weil sowieso alles brauchbar kodiert ist, weil man auch HW kaufen kann und weil "Performance-Diskussionen" mit Techies die Hölle sein können).