PHP - Breitensuche
-
Die Diskussion ist für mich gelaufen, ihr habt euch disqualifiziert.
-
314159265358979 schrieb:
Der TE meinte, wenn der Algorithmus in PHP zu langsam ist, nimmt er einen anderen. Vielleicht eher die richtige Programmiersprache für rechenintensives Zeug aussuchen, anstatt zu behaupten, der Algorithmus wäre ungeeignet.
lol, PIs gesicht möcht ich sehen wenn er in 5 Jahren zum ersten Mal in einem Hörsal sitzt und der Dozent versucht ihm das auszutrichtern
> Wenn der Algorithmus zu langsam ist einfach mal eine andere Sprache benutzen, und dann am besten das assembler optimieren
-
weißt du wie oft ich schon in js/php implementierten algorithmen gelesen hab, dass sie von c portiert wurden?
es gibt ein level an abstraktion, ab dem man einfach langsamer wird, weil man sich ständig für überdimensionierte algorithmen und datenstrukturen entscheidet. automatische typumwandlungen und immutable strings erledigen dann meist den rest.
jeder der hier behauptet, dass es nur auf den algo ankommt hat einfach keinen plan vom business... denn meist haben besser bezahlte programmierer auch mehr ahnung von algorithmen und der hardware und php ist neben js eine der schlecht bezahltesten sprachen der welt!
-
triptop schrieb:
denn meist haben besser bezahlte programmierer auch mehr ahnung von algorithmen und der hardware und php ist neben js eine der schlecht bezahltesten sprachen der welt!
Die bestbezahlten Programmierer sind laut c't für COBOL, ABAP und ähnliche Grausamkeiten unterwegs (ich hab die Ausgabe nicht mehr vorliegen, vielleicht mag das nochmal jemand verifizieren), das sind mit Sicherheit keine Algorithmen- oder Hardware-Experten. Am Gehalt würde ich es also nicht festmachen.
-
triptop schrieb:
jeder der hier behauptet, dass es nur auf den algo ankommt hat einfach keinen plan vom business... denn meist haben besser bezahlte programmierer auch mehr ahnung von algorithmen und der hardware und php ist neben js eine der schlecht bezahltesten sprachen der welt!
Ahja, es kommt nicht nur auf den Algorithmus an, denn besser bezahlte Programmierer haben mehr Ahnung von Algorithmen. LOL Alter! Wenn ich sowas lese, roflt es bei mir das Frühstück wieder hoch.
Die untere Schranke wurde mit O(n) schon genannt, die algorithmische Analyse ist damit abgeschlossen, die optimale Suche ist trivial. Dass PHP langsamer als eine C-Implementierung ist, hat hier niemand behauptet. Und generell kommt es natürlich nicht nur auf den Algorithmus an. Aussage hier war: in den meisten Fällen spielen bei Webanwendungen andere Kriterien eine Rolle.
Hast du das jetzt geschnallt? Wenn ja, erklär es noch PI.
-
Äh PHP "schneller" hat niemand behauptet!
LOL Alter! Wenn ich sehe, was ich schreibe, roflt es mir die Zehnägel quer.
-
mit typen, wo sich die zehennägel rofln und loln will ich nichts zu tun haben. ich schätze ernsthaftigkeit mehr als einen clown.
-
314159265358979 schrieb:
Aber extra für dich, ein kleines Benchmark, damit du einsiehst, was für fatalen Mist du von dir gibst.
Eine Astreine Themenverfehlung.
Weil du nicht kapierst worum es geht.Du hängst dich an Details auf die im Big-Picture(tm) irrelevant sind.
Schreib den Code mal so, wie er in der freien Wildbahn vorkommen würde. Nämlich mit caching und 1000 concurrent requests. Dann wirst du recht schnell feststellen, dass PHP um Dimensionen schneller ist oder du um Dimensionen mehr Zeit in das C++ Programm stecken musst.
Zum Mitschreiben: 1 Request ist vollkommen irrelevant. Die Performance einer Anwendung hängt davon ab wieviel concurrent requests sie bearbeiten kann.
-
du solltest langsam die fresse halten, bevor das noch jemand glaubt
-
Shade of Mine hat vollkommen recht. Es ist offensichtlich, dass du im Bereich Webentwicklung noch nicht wirklich an größeren Projekten mitgewirkt hast. Wie so oft ist nicht alles schwarz oder weiß - Entscheidungsfindungen hängen von mehreren Parametern ab und sind doch etwas komplexer als "Sprache A ist schneller als Sprache B".
Die einzigen, die hier im Unrecht sind, sind leider du und PI.
Damit wäre meine Frage, ob du es jetzt endlich geschnallt hättest, aber beantwortet. Welch überraschendes Resultat.
-
Hat mal jemand einen Link für Web-Dummies wie mich, der mal darlegt, warum PHP so gigantisch überlegen sein soll? Insbesondere das hier:
Shade schrieb:
Du hast nur 1 PHP Instanz aber N C++ Instanzen. DAS ist der Punkt. C++ ist nicht trivial Skalierbar auf den Server zu bekommen. CGI, FastCGI, etc. ist alles Schrott. Du brauchst einen App Server.
Wieso ist das alles Schrott, und wie funktioniert PHP dagegen?
Ich war immer der Ansicht, dass PHP nur deshalb so beliebt ist, weil es jeder Billighoster dabei hat. Stimmt ja offenbar nicht.
-
dann sollten sich wohl die zusammenschließen, die gleicher meinung sind. mit euch will ich eh nicht arbeiten, da liegen die meinungen einfach viel zu weit auseinander.
-
Bashar schrieb:
Shade schrieb:
Du hast nur 1 PHP Instanz aber N C++ Instanzen. DAS ist der Punkt. C++ ist nicht trivial Skalierbar auf den Server zu bekommen. CGI, FastCGI, etc. ist alles Schrott. Du brauchst einen App Server.
Wieso ist das alles Schrott, und wie funktioniert PHP dagegen?
Ich war immer der Ansicht, dass PHP nur deshalb so beliebt ist, weil es jeder Billighoster dabei hat. Stimmt ja offenbar nicht.
Das ist natürlich der Fall - also PHP ist so beliebt weil es so easy zu installieren ist.
PHP läuft als apache Module direkt im Kontext des Servers. Was enorme Performance Vorteile gegenüber zB CGI bringt. CGI ist ja sehr dumm und startet jedesmal einen neuen Prozess. FastCGI ist da schon etwas besser, aber immer noch nicht auf dem Niveau eines Apache Modules.
Das ganze kombiniert mit einem OpCode Cache reduziert die Startzeiten von PHP Code auf quasi 0. Das ist halt ziemlich genial - da man idR nur sehr wenig Zeit mit der Ausführung von Code verbringt. Das ist der große Vorteil von Sprachen wie PHP und Ruby gegenüber zB C++ Code.
Und dennoch ist alles gesandboxt. dh ein Request kann keinen anderen Request abschießen. Was gerade in shared Umgebungen Gold Wert ist.
PHP ist natürlich dennoch ziemlicher Schrott.
-
Shade Of Mine schrieb:
CGI ist ja sehr dumm
und php läuft nicht immer als modul. aber hey, mach was du willst! nimm meinetwegen php und js im backend aber verzapf das keinem, der nach ganz oben will!
-
Shade Of Mine schrieb:
PHP läuft als apache Module direkt im Kontext des Servers. Was enorme Performance Vorteile gegenüber zB CGI bringt. CGI ist ja sehr dumm und startet jedesmal einen neuen Prozess. FastCGI ist da schon etwas besser, aber immer noch nicht auf dem Niveau eines Apache Modules.
Und Apache ist der einzige relevante Webserver? Und es gibt keine C++-Module? Ich hab das Gefühl das ist kein technisches Argument, sondern wieder ein Verweis darauf, was verbreitet und üblich ist. Aber es ist auch nur ein Gefühl.
Das ganze kombiniert mit einem OpCode Cache reduziert die Startzeiten von PHP Code auf quasi 0.
Wieso sind die Startzeiten so relevant? Ein Prozess ist vielleicht nicht ganz so schnell gestartet, aber wenn dein PHP-Script im Sekundenbereich rumrödelt verblasst der Unterschied bei der Startzeit schnell.
-
Shade Of Mine schrieb:
Eine Astreine Themenverfehlung.
Weil du nicht kapierst worum es geht.Gebe ich gleich mal so an dich zurück. Es geht hier um den TE und sein Problem. Der TE sagt: Ich nehme PHP und Algorithmus X, aber das ist vielleicht zu langsam, vielleicht sollte ich mich nach Algorithmus Y umsehen. Darauf sage ich nur: PHP ist einfach langsam, nimm eine schnellere Sprache.
Um nichts anderes geht es hier. Wenn ich Performance brauche, dann nehme ich ganz sicher nicht PHP. Das war schon immer so und wird für ziemlich lange auch sicherlich noch so bleiben.
/eof
-
314159265358979 schrieb:
Shade Of Mine schrieb:
Eine Astreine Themenverfehlung.
Weil du nicht kapierst worum es geht.Gebe ich gleich mal so an dich zurück. Es geht hier um den TE und sein Problem. Der TE sagt: Ich nehme PHP und Algorithmus X, aber das ist vielleicht zu langsam, vielleicht sollte ich mich nach Algorithmus Y umsehen. Darauf sage ich nur: PHP ist einfach langsam, nimm eine schnellere Sprache.
Genau dies zeigt den Unsinn, nicht die Sprache entscheidet die Ausführungsgeschwindingkeit des Programms sondern seine Implementierung ( Was denkst du warum mein Javascript-Beispiel zu gut abschneiden im Vergleich zu deinem PHP-Code). Seine Problemgröße rechtfertig ein Umstieg nicht im Ansatzweise. Bleibt ihm noch frei Optimierungsstategie die Logik in die Datenbank abbilden und andere Implementierungen zu benutzen(hiphop, pdc, hiphop-vm...) anzuwenden. Evtl. sprechen andere Faktoren doch für die Implementierung mit C++, Webserver mit FastCGI ist schon vorhanden, Webserver ist keiner mit Anderem geteilt... was auch immer. Aber diese Pauschalargumente geht mir echt auf die Eier.
-
Blablablabla. Mimimimi. Hör doch auf mit dem Gedöns. Niemand, aber auch wirklich niemand, der Performance braucht, nimmt PHP. Frag Google. Frag Facebook.
-
314159265358979 schrieb:
Blablablabla. Mimimimi. Hör doch auf mit dem Gedöns. Niemand, aber auch wirklich niemand, der Performance braucht, nimmt PHP. Frag Google. Frag Facebook.
Facebook nutzt PHP! Deswegen investieren sie in bessere Implentierung - siehe Hiphop Compiler und hhvm.
-
Facebook nutzt einen PHP zu C++ Compiler, weil PHP zu langsam ist. Das würde ich nicht als Pluspunkt für PHP werten.