ZUdem Script:
Legt file get contents in den Ram.
Vergleichst du Tomaten mit Äpfel, den fgets Zeilenweise einliest wäre dumm wenn das schneller gehen würde
Nein ich vergleiche nicht Tomaten mit Äpfeln. Ich habe vorhin gesagt, dass file_get_content() schneller zu Dateien lesen ist, als die anderen. Die anderen lesen auch Dateien und sind auch dafür da.
Aber allgemein ist das doch zu bevorzugen, da es sich dem Bildschirm anpasst? Liege ich falsch, hat mein dozent erzählt
Jain. Es ist natürlich von Vorteil, wenn eine Seite mit einer Auflösung 1024px genauso gut angezeigt wird, wie mit 1240px.
Aber wenn du mal logisch nachdenkst: Es kann gar nicht gut gehen, wenn man eine Seite auf einem 17 Zoll Bildschirm genauso darstellen will, wie auf einem Handy.
Eines der beiden würde extrem verzerrt wirken.
Kurze Nebenfrage:
Warum machst du nicht einfach per CSS ein overflow:hidden; oder overflow:scroll; in den Container für den Text?
Der User ist doch selbst Schuld, wenn er 150 Zeichen ohne Whitespaces macht. Wirds halt nicht angezeigt, oder man muss scrollen bei dem einen Beitrag.
Nein. PHP kann nicht wissen, wie breit dein text ist.
Jain. Ja, wenn doch beschränkt:
http://php.net/manual/en/function.imagettfbbox.php
<html><head><title>Test</title>
<script type="text/javascript">
function Geheim () {
var Passwort = "Anton";
var Eingabe = document.getElementsByName("Eingabe")[0].value; // ----- hier
if (Eingabe == Passwort) { location.href = "geheimerbereich.html"; }
else {location.href="falschespasswort.html";}
}
</script>
</head><body>
<h1>Der Sinn des Lebens</h1>
<form action="Formular">
<p>Was ist der Sinn des Lebens?</p>
<input type="password" name="Eingabe" size="40">
<input type="button" value="OK" onclick="Geheim()">
</form>
</body></html>Doch "Schutz" ist hier relativ. Das Beispiel, das du hier von SelfHTML hast ist sehr, sehr schwach 
Also ich finde ein liquides Design für Handys relativ nutzlos.
Denn du musst beachten, wann Leute mit dem Handy auf deine Webseite sehen.
Eine normale Seite für den Bildschirm sollte ansprechend und vielseitig gestaltet sein.
Handysurfer wollen jedoch oft nur schnell gewisse Informationen nachsehen.
Diese sollten auch schnell erreichbar sein. Darum sollte auf dem Handy nicht direkt die fülle an Informartionen, ein ansprechendes Design und eine Vielzahl an Zusätzen im Mittelpunkt stehen - wie am Bildschirm -, sondern eher eine schnelle, einfache Navigationen, die klar auf die gewünschten Seiten führt.
@Dodo vergiss es KingCrunsh ist ein PHP Kenner
Also wenn ich mir den Stuss über OOP uns file_get_contents() durchlese, dann kann ich über diese Behauptung wirklich nur lachen.
Wenn diese Optimierungen bei dir einen enormen Schub gebracht haben dann muss ich echt sagen das du was falsch gemacht hast
Ja ich weiß, dass ich was falsch gemacht habe. Ich habe ja auch dazugeschrieben, wrlche Punkte ich alle berücksichtigt habe. Mir vielen heute noch ein paar Schleifendurchgänge auf, die man sparen kann. Jetzt benötigt die Suchfunktion nur noch etwa eine halbe Sekunde.
Ich WEI?, dass ich das Script vorher schlecht programmiert habe und deswegen hab ich ja auch nach Optimierungen gesucht. Und diese Optimierungen habe ich gefunden. Und sie haben einen enormen Schub gebracht. Deshalb wollte ich das hier posten.
Denn, wenn jemand mal dasselbe Problem hat, dann kann er hier vielleicht Lösungsansätze finden.
Lieber KingCrunch:
Ich habe am Ende meiner Beitrags meine Hauptquelle gepostet. Ich behaupte nicht, wenn ich nicht vorher von mehreren diese Aussage bestätigt bekommen habe.
Ja, auch viele Punkte sind allgemein. Das ist nunmal so, wenn man eine CODE-Optimierung anwendet. Code gibts in jeder Sprache und sieht in den meisten Hochsprachen gleich aus.
Und zu den trivialen Punkte. Ja. Sie sollten klar sein, aber sie passieren trotzde,. Und wenn nur EINER keinen count()-Befehl mehr in den Schleifenkopf postet, hat sich sich mein Beitrag bereits ausgezahlt.
Zu OOP: Eine interpretierte Sprache verhält sich keinesfalls wie eine ausgeführte Sprache. Zuerst muss auf syntaktische Korrektheit geprüft werden - Das fällt durch das Compilieren weg bei ausgeführten Sprachen weg. Bei Compilierte Sprachen werden Klassen im vornherein in eigene Speicherstrukturen umgewandelt. Das kann bei PHP nicht der Fall sein, weil diese Struktur bei jedem Script-Aufruf berechnet und erstellt werden muss. Beim Zugriff auf Objekte muss in PHP jeder Teil einzeln aufgelöst werden. Dass da viel berücksichtigt wird, zeigt, dass $this->$variable klappt. Da wird sogar die Position der Speicherzelle errechnet.
Dieses ganze Rechnen fällt bei compilierten Sprachen weg, weil alles auf statische Speicheradressen umgerechnet wird.
Bei normalen Variablenzugriffen unter PHP fallen all die Punke auch weg, weil keine Objekte berücksichtigt werden. Und da sollte jedem Menschen mit etwas programmiertechnischen Hausverstand klar sein, dass OOP in PHP - relativ gesehen - enorme Geschwindigkeitseinbußen bringt.
War das eines der "Argumente", das du gemeint hast? Wie wäre es, wenn du dich selbst mal mit ein paar anderen Sprachen auseinandersetzt, damit du vergleichen kannst...
Und ich will PHP keinesfalls "dissen", wie du gemeint hast. Ich programmiere nun jahrelang PHP und bevorzuge diese Sprache, wegen der Dynamik des Syntax. Aber ist nunmal Fakt, dass PHP im Bereich der Geschwindigkeit neben seinen großen Kollegen, wie JSP oder ASP.NET untergeht.
Deswegen wollte ich den Code schreiben. Denn gerade die Dynamik des PHP-Codes ist das, was Programmierer dazu verleitet, ineffizienten Code zu schreiben.
Edit: Zu dem mit dem Dateien lesen:
Ich hab gerade ein Testscript geschrieben. Drei absolut gleiche Archive - nur der Name unterscheidet sich.
Jedes Archiv wird mit folgendem Code zehn mal eingelesen:
<?php
$start = microtime(true);
for($i = 0; $i < 10; $i++)
$f1 = file_get_contents('e1.zip');
$zwischenzeit1 = microtime(true);
for($j = 0; $j < 10; $j++)
$f2 = file('e2.zip');
$zwischenzeit2 = microtime(true);
for($k = 0; $k < 10; $k++)
{
$f3 = '';
$handle = fopen("e3.zip","r");
while (!feof($handle))
$f3 .= fgets($handle, 4096);
}
$zwischenzeit3 = microtime(true);
echo "file_get_contents(): ".($zwischenzeit1 - $start)."\n";
echo "file(): ".($zwischenzeit2 - $zwischenzeit1)."\n";
echo "fgets(): ".($zwischenzeit3 - $zwischenzeit2)."\n";
?>Folgende Ausgabe kam zustande:
file_get_contents(): 0.86298608779907
file(): 1.2042920589447
fgets(): 2.545175075531
So... Ich warte auf deine Antwort, toller PHP-Kenner... -.-
Edit2: Zu dem mit dem schneller gehen: Hab ich doch gesagt. Ich ich erinnere mich niemandem gesagt zu haben, er/sie solle unsauber programmieren.
Zuerst zu deiner Liste womit man extremviel Zeit einsparrt:
JA, man siehts an meiner Suchfunktion ;D
4. erreg Funktionen sollten nicht mehr verwendet werden..
Hab ja auch niemandem gesagt, er soll sie verwenden, sondern eher hab eher abgeraten, oder? ;D
9. OOP wird nicht verwendet um Speed zu sparen, wer ohne OOP arbeitet wegen Speed der hat selber Schuld
Ja ich weiß, aber bei Scripts, die an sich schon viel LAufzeit benötigen, muss man diese nicht noch weiter raussteigern, oder?
Auf die anderen WICHTIGEN Sachen gehe ich mal nicht ein
Die wären? Ich habe nicht gesagt, dass alle viel bringen. Aber jeder bringt etwas. Und dies wird addiert. Vor allem die Schleifen fallen da rein.
Nun zu wichtigen womit man wirklich Zeit sparrt:
1. Cache verwenden sprich DB abfragen, Datensätze cachen (Zend Cache oder ähnliches)
2. Kompilierter Quelletext zwischenspeichern mit zb APC
3. Queries meiden
Das was ich damit bezwecken wollte, ist die Script-Optimierung, weil gerade hier die größten Fehler gemacht werden. Warum, denkst du, bin ich denn auf die letzten beiden Punkte nicht näher eingegangen?
Naja mein Bruder ist grad mitten im Master von Wirtschaftsinformatik an der TU Wien O.o
grml, mein nächster Urlaub wird an Weihnachten sein
mein letzter Urlaub war im Februar
Haben Studenten nicht drei Monate frei? O.o
Mein Bruder sitzt hier jedenfalls die ganze Zeit rum^^
Also mein Browser (Opera 10.60) unterstützt die von mir hier verwendeten Html5 Elemente.
Wie gesagt ohne das verschachtelte "<ul>" wird alles korrekt angezeigt.MFG Matthias.
Opera ist in Sachen HTML5 auch vorbildlich. Was ich gelesen habe, kann IE bis Version 7 oder 8 HTML5-Elemente nicht oder kaum anzeigen.
So, aus gegebenen Anlass, möchte ich euch das Thema Geschwindigkeit in PHP näher bringen.
Das Ganze begann am Wochenende mit einer Diskussion zwischen meinem Bruder und mir mit dem Thema "Performance und Syntax von PHP". Es ist wohl klar, dass PHP in Sachen Geschwindigkeit nicht mit den Kontrahenten ASP.NET, JSP oder Python mithalten kann. PHP ist nun mal eine interpretierte Sprache und bietet damit nur eine relativ dürftige Performance.
Das musste ich gestern in der Arbeit hart zu spüren bekommen. Ich entwickelte eine Suchfunktion für das aktuelle Projekt. Die Seite hat etwas mehr und größere Unterseiten und ich wollte keinen heuristischen Algorithmus entwickeln, sondern möglichst gute Ergebnisse geliefert bekommen. Außerdem sollte die Suche auf aktuelle Daten und nicht auf Indizes zugreifen.
Das Ergebnis konnte sich sehen lassen: Tests ergaben die Ergebnisse, die wirklich perfekt passten. Doch das große Manko: Weil Tag-Clouds, Meta-Tags, Überschriften und Texte und Alternativtexte von Bildern einzeln gewichtet werden und deshalb einzeln geparst werden; weil passende Stücke aus durchaus großen Seiten herausgepickt werden (mit konfigurierbarer Länge); und weil Treffer visuell in den Abschnitten hervorgehoben werden - dauerte die Suche bei einer Stichwortsuche mit drei Begriffen in etwa drei Sekunden - Viel zu lange, für eine Suchfunktion einer Website!
Deshalb habe ich mich etwas mit Geschwindigkeitsoptimierung von PHP-Scripten beschäftigt. Und siehe da: Ein paar kleine Änderungen hier und da: Qualitativ gleichbleibende Ergebnisse mit etwa einer Sekunde Laufzeit.
Die wichtigsten 20 Punkte im Bereich PHP-Geschwindigkeitsoptimierung möchte ich euch im Folgenden präsentieren.
Viele haben erst Auswirkungen, bei vielen Schleifendurchläufen oder langen Texten, doch alle haben einen Effekt - wie man an meinem Script sieht.
------------------------------------
01. "Hallo ".$world; ist schneller als "Hello $world";. Das kommt daher, weil PHP beim parsen eines Strings
viele Zeichen überprüfen muss. Durch das beenden des Strings vor dem Anketten einer Variable lässt PHP in einen dementsprechend schnelleren Modus umspringen.
02. ' ist schneller als ". Dies hat einen ähnlichen Grund viel der vorherige Punkt. Bei " müssen einfach viel mehr steuerzeichen überprüft werden, als bei ', wo PHP mehr oder minder einfach drüberfährt.
03. file_get_contents() und file_put_contents() ist schneller, als andere Methoden, um Dateien zu lesen. Die kommt ganz klar daher, dass PHP intern einfach keine Arrays oder ähnliches konstruieren muss.
04. strpos() ist schneller als preg_match() - preg_match() ist schneller als ereg() - Auch die entsprechenden Replace-Funktionen. Das sollte auch jedem klar sein sein, warum. Deshalb immer vereinfachen versuchen.
05. Bei zu speichernden Daten viel beim Eintragen rechnen. Auslesen kommt öfter vor. Wenn ihr etwa in Datenbanken, Dateien, o.Ä. eintragt, rechnet eher beim Eintragen. Wenn der Eintrag zehn mal ausgelesen wird, erspart ihr euch auch zehn Rechenzyklen.
06. Wenn möglich, den Output zusammenfassen und auf einmal ausgeben. Die kommt daher, weil echo & Co. mit Datenverkehr verbunden wird. Das erklärt auch den häufigen header()-Fehler. Ein Template-System kann da viel helfen.
07. PHP-Tags schließen, wenn ein langer Text ausgegeben wird. Bevor man mit echo einen langen Text, wie zum Beispiel den Grundaufbau der Seite ausgibt, sollte man eher mit ?> den PHP-Code beenden und auf "Inline-PHP" zugreifen.
08. Output-Buffering und GZip-Kompression verwenden (falls möglich) ob_start() ist eine der nützlichsten funktionen in diesem Bereich. Hier wird jeglicher Output zwischengespeichert und kann anschließend, ähnlich einem Template-System verabreitet werden. Auch GZip-komprimierte Datenübertragungen können viel Geschwindigkeit bringen.
09. OOP vermeiden. OOP ist eine grandiose Erfindung. Aber nicht für PHP. PHP ist und bleibt eine interpretierte Sprache. Und jede Klasse muss zuerst geparst werden. Außerdem dauert der Zugriff auf Elemente einer Klasse vier mal länger, als auch normale Variablen.
10. Beim komplexen Algorithmen Schleifendurchgänge zusammenfassen. Falls ihr schon eine etwas komplexere Funktion mit vielen Schleifen geschrieben habt, werdet ihr die Gecshwindigkeit-Lecks von PHP sicher auch schon gesehen haben. Hier hilft es oft Schleifendurchgänge zusammenzufassen und Ausnahmekriterien (wie ersten und letztes Element) explizit zu behandeln. So fällt die überprüfung weg.
11. Auch mal Heuristiken verwenden. Ein Algorithmus muss nicht immer perfekte Ergebnisse liefern. Gute reichen oft auch. Durch einen einfachen Denkanstoß, kann eine Heuristik große Geschwindigkeitsscüber bringen.
12. Viel in den Speicher laden und auf Variablen zurückgreifen, nicht auf Funktionsaufrufe. Wenn ihr die Länge ienes String zehn mal bestimmen müsst, berechnet sie einmal und speichert sie in einer Variable. Zehn mal strlen() benötigt auch eine entsprechend höhere Laufzeit.
13. Keine gleichbleibenden Berechnungen in Schleifen lassen, sondern vor die Schleife setzen. Niemals eine Schleife in der Form "for($i = 0; $i < count($array_a); $i++)" implementieren. Bei jedem Schleifendurchgang wird die mittlere Bedingung geprüft. Lieber vor der Schleife in eine Variable schreiben. Das gilt auch für Berechnungen innerhalb der Schleife, die in jedem Durchgang dasselbe Ergebnis liefern.
14. Möglichst simple Variablen-Typen an Unterprogramme übergeben. Arrays und Objekte benötigen viel Rechenzeit. Deshab lieber die gewünschten Werte beim Aufruf auslesen und einzeln übergeben.
15. Objekte und Arrays als Referenzen übergeben. Wenn es wirklich notwendig ist, Arrays und Objekte an Unterprogramme zu übergeben, tut dies per & und macht sie zu Referenzen. PHP kann darauf schneller zugreifen.
16. Nicht mehr gebrauchte Arrays und Objekte per unset() löschen. Gerade diese großen Variablentypen benötigen viel Speicher. Wer sich schon mal mit dem Speicheraufbau eines Prozessors beschäftigt hat, wird mir zustimmen, dass das freigeben großer Bereiche Leben retten kann.
17. Möglichst wenig Funtkionsaufrufe, wenn sie nicht unbedingt notwendig sind. Jeder Funktonsaufruf benötigt mehr Zeit, als eine normale Iteration. Deshalb lieber mal Code zwei oder drei mal kopieren, anstatt unnötige Unterprogrammaufrufe zu starten.
18. Datenbanken sollten unbedingt indiziert werden. Das betrifft zwar nicht direkt PHP, aber viele Anwendungsbereiche PHPs. MySQL & Co. bekommen einen enormen GEschwindigkeitsschub durch einen Index.
19. Zend bietet einen PHP Optimizer an, der das Laden und Interpretieren bis zu doppelt so schnell machen kann. Erklärt sich glaub ich von selbst ;D
20. Webserveroptimierung: Das größte Optimierungspotential steckt jedoch im Server. Wie man diese genau konfigurieren sollte, könnt ihr hier nachlesen: http://phplens.com/lens/php-book/…bugging-php.php
------------------------------------
Ich hoffe, ich konnte euch das Thema "Geschwindigkeit und PHP" etwas näher bringen. Ich wünsche euch viel Glück bei großen Projekten. Eure Benutzer werden euch kurze Rechenzeiten danken 
Bei meinem Script wurden vor Allem folgende Punkte implementiert: 01, 02, 03, 04, 06, 09, 10 (!), 12, 13, 14 15, 17.
Liebe Grüße
Dodo
Was soll das bringen? Selten sowas unnützes gesehen...
Man macht Dinge nicht immer, weil sie Sinnvoll sind. Warum spielen so viele Leute Videospiele?
Es geht hier eher darum, den Leuten zu zeigen, was alles möglich ist, wenn man nur weiß, wie.
Und das mit möglichst einfachen Mitteln. Das gibt Denkanstöße - und diese bringen oft ganz nützliche Dinge.
Ähm... Eine kurze Frage: Führst du das lokal aus oder über einen Server?
Und wie bekommt er den Inhalt an ein PHP-Script?
Der Inhalt wird sowieso mit JS erstellt. Und sogar IE 6 beherrscht AJAX.
Also kann man gleich mit JS das Ganze an den Server schicken.
"funktioniert nicht" ist KEINE (!) gute Beschreibung.
Was macht er? Was macht er nicht? Was wird ausgegeben? Was siehst du? Etc.?
Und was passiert und passiert nicht?
"geht nicht" ist keine genaue Problembeschreibung
Ich sehe hier auch keinen PHP-Code.
Ohne Code kann man dir nicht helfen.
Warum verwendest du nicht einen einfachen Form-Mailer-Service?
Okay, dann poste hier mal die Funktion, die aufgerufen wird, wenn der nächste Slide gestartet wird.
