PHP - Breitensuche
-
Hi,
ich würde gern die Breitensuche in PHP umsetzen. Jetzt befürchte ich aber, das solch ein Algorithmus ziemlich viel Arbeitsspeicher braucht je nach Größe der Matrix.
Kann man sowas vorher irgendwie abschätzen, denn je nach dem müsste ich einen anderen Algorithmus probieren?
Grüße
-
00Albert schrieb:
denn je nach dem müsste ich einen anderen Algorithmus probieren?
Oder eine andere Sprache.
-
Was würde das für einen Unterschied machen? Das ganze soll als Webanwendung benutzbar sein daher dachte ich an PHP.
-
Um wie viele Elemente geht es?
-
00Albert schrieb:
Was würde das für einen Unterschied machen?
PHP ist um Faktor 10-100 langsamer als z.B. C++.
-
314159265358979 schrieb:
00Albert schrieb:
Was würde das für einen Unterschied machen?
PHP ist um Faktor 10-100 langsamer als z.B. C++.
Kommt immer auf die Situation an. PHP ist schon recht schnell, das ist trivial mit C++ nicht einholbar. Im Web geht es naemlich nicht um Geschwindigkeit sondern Skalierbarkeit. Das lernst du dann, wenn du gross bist
@00Albert:
Du hast O(N) speicherkomplexitaet wenn ich das richtig sehe. Das sollte doch erstmal kein Problem sein. Wieviele Elemente willst du denn haben? uU gibt es bessere Strukturen das abzulegen. Im Idealfall kann man deine Struktur vielleicht sogar direkt in der DB ablegen, dann bist du enorm schnell.
-
Naja c++ bekomm ich aber nicht in den browser oder ich wüsste nicht wie.
Das ganze Gebilde meines Testsenarios hat 300 Knoten und mindestens 900 Kanten, hab noch nicht alles aus der Grafik abgeschrieben, wobei das alles ungerichtet ist.
Meine Idee war aber, da der Algorithmus dann ja universell wäre, das man per CSV jeweils neue Graphen hochladen kann. wobei ich erstmal keine Datenbank zwischenschalten wollte. Das würde vermutlich am möglichen Speicherverbrauch auch nichts groß ändern ob mit oder ohne DB, oder?
Edit:
Was bedeutet O(N)? Also die Geschwindigkeit wäre jetzt nicht ganz so wichtig eher der nötige Arbeitsspeicher für den Server, da die meißten Serverangebote stark begrenz sind Aber gut wenn das echt sonen vorteil bringt muss ich über eine DB nochmal nachdenken, hätte das sonst alles über dynamische arrays vorgehalten, sind ja alles Matrizen.
-
Shade Of Mine schrieb:
314159265358979 schrieb:
00Albert schrieb:
Was würde das für einen Unterschied machen?
PHP ist um Faktor 10-100 langsamer als z.B. C++.
Kommt immer auf die Situation an. PHP ist schon recht schnell, das ist trivial mit C++ nicht einholbar. Im Web geht es naemlich nicht um Geschwindigkeit sondern Skalierbarkeit. Das lernst du dann, wenn du gross bist
so ein schrott. im web geht es mehr als iwo anders um geschwindigkeit, kosten und ökologie! und in allen drei punkten verliert php und zieht dich und deine argumente mit!
-
eig. hätt ich eh nach 'trivial' nicht weiterlesen brauchen. ein wort für looser
-
der einzige grund, weshalb man php verwenden sollte, ist etwas, was bwl'ler mit TTM bezeichnen.
das hat aber mit skalierbarkeit und sonstigen 'programmiertechnischen aspekten' nichts am hut.
häufig sieht man dann bei solchen 'geskripteten' seiten, wie die performance bei wachsender beliebtheit zusammenbricht und alle versuche es mit einem flickenteppich an updates aufzupolieren scheitern
-
00Albert schrieb:
Das ganze Gebilde meines Testsenarios hat 300 Knoten und mindestens 900 Kanten, hab noch nicht alles aus der Grafik abgeschrieben, wobei das alles ungerichtet ist.
Selbst für PHP sollte es Kleinkram sein.
-
Shade Of Mine schrieb:
PHP ist schon recht schnell, das ist trivial mit C++ nicht einholbar.
Ein rekursiver Fibonacci reicht bereits aus.
00Albert schrieb:
Naja c++ bekomm ich aber nicht in den browser oder ich wüsste nicht wie.
Entweder aus PHP aufrufen, oder über CGI.
-
314159265358979 schrieb:
Shade Of Mine schrieb:
PHP ist schon recht schnell, das ist trivial mit C++ nicht einholbar.
Ein rekursiver Fibonacci reicht bereits aus.
Nope, da bin ich dank Caching mit PHP schneller - weil ich mehr concurrente Anfragen beantworten kann.
@triptop:
Nope, im Web geht es um Skalierbarkeit. Ein Request interessiert nicht. Wenn der Request in einer Zeit abgearbeitet werden kann die OK ist, dann passt das. Die Frage ist: wie schaut es mit 1000 Requests pro Sekunde aus oder 100000?Das ist die relevante Frage. Ein Request ist uninteressant.
@00Albert:
Wie Zeugs schreibt, das ist Kleinkram.Der richtige Ansatz zur Optimierung ist eher: wie kann ich diese Struktur in der Datenbank abbilden. Und wie kann ich dann darauf die notwendigen Operationen machen, so dass ich in PHP garnicht erst irgendwas tun muss.
-
Shade Of Mine schrieb:
@triptop:
Nope, im Web geht es um Skalierbarkeit. Ein Request interessiert nicht. Wenn der Request in einer Zeit abgearbeitet werden kann die OK ist, dann passt das. Die Frage ist: wie schaut es mit 1000 Requests pro Sekunde aus oder 100000?Das ist die relevante Frage. Ein Request ist uninteressant.
willst du mich ärgern? wenn eine php version 10 anfragen pro sek. schafft, aber eine c version 1000 pro sek., wie macht dann ein vor- oder nachgeschalteter loadbalancer php schneller
klar, sind 100 php instanzen dann gleich schnell wie eine c instanz aber doch nicht wie 100 c instanzen!
-
und nochmal, wie pi schon richtig behauptet hat, wir reden hier leicht um faktor 10 und manchmal 100! das bedeutet, dass du 100 mal mehr strom verbrauchst und 100 mal mehr schrott produzierst, weil solche it-systeme idr. iwann unwirtschaftlich werden, wenn sie vorher nicht ausgefallen sind...
-
Shade Of Mine schrieb:
Du hast O(N) speicherkomplexitaet wenn ich das richtig sehe.
Eine Adjazenzmatrix hat die Größe n². Macht bei 300 Knoten 90000 Einträge. Viel billiger kommt man hier weg, wenn man eine Adjazenzliste benutzt, die nur
9001800 Einträge benutzt. Dann läuft der Algorithmus nebenbei auch noch deutlich schneller.
-
triptop schrieb:
willst du mich ärgern? wenn eine php version 10 anfragen pro sek. schafft, aber eine c version 1000 pro sek., wie macht dann ein vor- oder nachgeschalteter loadbalancer php schneller
Und wenn PHP 1000 pro Sek schafft und C nur 10 dann ist PHP schneller.
Was ist der Sinn von so einem Schwachfug?
klar, sind 100 php instanzen dann gleich schnell wie eine c instanz aber doch nicht wie 100 c instanzen!
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. Da gibts nicht viele die was bringen. Und selbst dann gewinne ich idR durch andere Methoden mehr Performance.
Die Sprache ist idR komplett uninteressant.
@Michael E.:
Und das müsste sich eigentlich in einer Tabellenstruktur abspeichern lassen. Damit kann ich direkt über SQL darauf suchen.Und alles was ich in der DB halten kann, ist halt enorm schnell und skaliert wie sau
-
Shade Of Mine schrieb:
Und alles was ich in der DB halten kann, ist halt enorm schnell und skaliert wie sau
okay, ich denke wir lassen das jetzt. ich geh jetzt bischen spazieren und dann gibts krieg in der champions league
-
Shade Of Mine schrieb:
Und wenn PHP 1000 pro Sek schafft und C nur 10 dann ist PHP schneller.
Was ist der Sinn von so einem Schwachfug?
http://i3.kym-cdn.com/photos/images/newsfeed/000/218/902/this%20is%20a%20viking%20biker%20arguement%20invalid.jpg
Ehrlich, so viel Mist hab ich schon ewig nicht mehr gelesen, musste fast lachen.Aber extra für dich, ein kleines Benchmark, damit du einsiehst, was für fatalen Mist du von dir gibst. Gegeben seien die beiden folgenden Programme:
<?php function fib($n) { return $n > 1 ? fib($n - 1) + fib($n - 2) : 1; } $begin = microtime(true); echo fib(35); $end = microtime(true); echo "<br />".($end-$begin); ?>
#include <iostream> #include <ctime> unsigned fib(unsigned n) { return n > 1 ? fib(n - 1) + fib(n - 2) : 1; } int main() { auto begin = std::clock(); std::cout << fib(35); auto end = std::clock(); std::cout << "<br />" << (end - begin) / static_cast<double>(CLOCKS_PER_SEC); }
Ausgabe PHP:
14930352
16.2973461151Ausgabe C++:
14930352
0.0403Ohne Worte...
-
Mein Gott, bist du schlecht in deine Haut will ich nicht sein. Ich bin mit JavaScript viel schneller
function fib(n) { return n > 1 ? fib(n-1) + fib(n-2) : 1; } var start = new Date(); console.log(fib(35)); var end = new Date(); console.log((end - start) / 1000);
14930352
0.288
-
Berechne es doch mit Template Magie zur Compile Zeit, dann bist du schnell