[PHP]stringBetween Funktion

[YatoDev]

Originally Posted by MrSm!th

@FlutterShy
Nur dass es hier nicht um AutoIt geht.

Ich kann auf meinem pc im moment keinen vergleich von 2 php funktionen machen aber RegEx ist besser

Originally Posted by Mostey

....

1.)In autoit bin ich es gewohnt alles so zu programmieren das es möglichst schnell ausgeführt wird weils einfach langsam ist.

2.)User requestet deine php seite. Dann führt php Stringbetween aus und gibt das aus und da entsteht die ladezeit oder ?

[Mostey]

Originally Posted by »FlutterShy™

Ich kann auf meinem pc im moment keinen vergleich von 2 php funktionen machen aber RegEx ist besser



1.)In autoit bin ich es gewohnt alles so zu programmieren das es möglichst schnell ausgeführt wird weils einfach langsam ist.

2.)User requestet deine php seite. Dann führt php Stringbetween aus und gibt das aus und da entsteht die ladezeit oder ?

Du hast meinen Post nicht verstanden, man kann dies trotzdem so implementieren, das der Aufruf dieser Funktion nicht einmal vom User bemerkt wird.

[dowhile]

Originally Posted by Mostey

Es geht hier aber sicher nicht um ein paar Millionen Zeichen. Das dürfte ja klar sein das es sich dann um viele Sekunden handelt die das Programm / die Anwendung ausbremsen und sich dann RegEx natürlich mehr rentiert wenn dieser Text sehr oft behandelt werden muss.

Aber wie wäre es, wenn man mal etwas realistischer denkt? Wann hat man schon so eine große Masse zu vergleichen? Hier ist nicht mal ein richtiger Kontext gegeben.

Ob ich jetzt ein mal 500 ms warten muss oder 2ms. So lange es ein mal vorkommt ist es kein Thema. Ich bleibe dabei und muss mir sicher nicht von dir sagen lassen, das ich aufgrund meiner Meinung nicht das tun soll, was ich möchte.

Wenn du vier solcher Stellen auf einer Seite hast musst du schon zwei Sekunden warten.

Fassen wir also zusammen:
* Dein Quelltext ist fehleranfälliger. Am Anfang hast du die Rückgabe von strpos() dadurch validiert, ob es ungleich -1 ist. Das war falsch, da strpos() wenn es nichts findet "false" zurück gibt. Dein jetzige Version ist aber noch immer falsch, da du nur den Wert und nicht den Typ vergleichst. Du behandelst also den Fall "nicht gefunden" und "an Position 0 gefunden" gleich, das geht nicht.

* Du schreibst viel(!) mehr Quelltext: Anstatt einer Zeile siehst du acht Zeilen als übersichtlicher beziehungsweise sauberer an. Dabei sind diese acht Zeilen sicherlich ebenso komplex wie ein Regexp mit gleicher Funktion.

* Noch einmal zum Thema Fehleranfälligkeit und Übersichtlichkeit: Ich muss immer etwas überlegen, ob ich bei einer Positiom / einer Länge im String jetzt noch 1 dazu oder abziehen (oder gar nichts tun) muss. Ist das bei euch nie der Fall?

* Deine Variante ist um Faktor 325 langsamer (in der Zeit, in der dein Algorithmus also 460 Wörterbucheinträge bearbeitet hätte hätte die Regexp Variante den ganzen Duden durch)

* Deswegen ist das mögliche Einsatzgebiet stark beschränkt (keine größere Datenmenge, kein low-level Code der öfters aufgerufen wird, ...)

* Das alles ist aber völlig i.O, weil wie oben beschrieben, acht fehleranfällige Zeilen viel einfacher zu verstehen sind als ein sechs Zeichen Regexp.

Mkay. Hast du schonmal über einen beruflichen Werdegang bei Sun nachgedacht? Die Typen die die Java-API schreiben brauchen Leute wie dich!

Ich schlage dann grundsätzlich immer zwei Versionen der Methoden vor:

* eqauls_normal()
* equals_slowAndLongButKindaEasyToUnderstand()

[Mostey]

Originally Posted by dowhile

Wenn du vier solcher Stellen auf einer Seite hast musst du schon zwei Sekunden warten.

Na dann nenn mir mal Beispiele in denen in ich 54,6 Millionen Zeichen (!!!!) durchsuchen muss. Und vor allem gehst du bitte nicht davon aus, das wenn es sich immer um den gleichen Text handelt der selbe Text immer wieder neu durchsucht wird.

Originally Posted by dowhile

* Dein Quelltext ist fehleranfälliger. Am Anfang hast du die Rückgabe von strpos() dadurch validiert, ob es ungleich -1 ist. Das war falsch, da strpos() wenn es nichts findet "false" zurück gibt. Dein jetzige Version ist aber noch immer falsch, da du nur den Wert und nicht den Typ vergleichst. Du behandelst also den Fall "nicht gefunden" und "an Position 0 gefunden" gleich, das geht nicht.

Ich habe den Code nicht geschrieben, wende dich dazu bitte an denjenigen, der den Code hier veröffentlicht hat. Außerdem kann man diese Defizite leicht beseitigen.

Originally Posted by dowhile

* Du schreibst viel(!) mehr Quelltext: Anstatt einer Zeile siehst du acht Zeilen als übersichtlicher beziehungsweise sauberer an. Dabei sind diese acht Zeilen sicherlich ebenso komplex wie ein Regexp mit gleicher Funktion.

Ich muss ja schon sagen, 7 Zeilen mehr sind natürlich sehr viel. Man bedenke, das du die Funktion so oder so nur einmal schreibst. Daher spielt diese Funktion in der Übersichtlichkeit eine große Rolle, da selbst Programmierer die keine Erfahrung mit regulären Ausdrücken haben, prima verfolgen können, was diese Funktion genau tut.

Originally Posted by dowhile

* Noch einmal zum Thema Fehleranfälligkeit und Übersichtlichkeit: Ich muss immer etwas überlegen, ob ich bei einer Positiom / einer Länge im String jetzt noch 1 dazu oder abziehen (oder gar nichts tun) muss. Ist das bei euch nie der Fall?

Und ich verweise noch einmal darauf, das ich den Code nicht verfasst habe. Das ist aber (wie dein anderes Argument auch) nichts, was nicht behoben werden kann.

Originally Posted by dowhile

* Deine Variante ist um Faktor 325 langsamer (in der Zeit, in der dein Algorithmus also 460 Wörterbucheinträge bearbeitet hätte hätte die Regexp Variante den ganzen Duden durch)

6500 char Strings * 2100 Stellen im Text in denen genannte Größe vorkommt: 13.650.000 Zeichen. Dafür braucht die Funktion 450 ms, aufgerundet auf 0,5 Sekunden.

Ein Duden hat ungefähr (je nach Auflage verschieden) ~50.000 Wörter. Nimmt man jetzt einen Durchschnitt von 6 Zeichen pro Wort, kommen wir auf 300.000. Also könnte man sagen, ein Duden ist 300.000 Zeichen groß. Eine Suche nach Dieser Anzahl an Zeichen dauert dementsprechend ~68ms.

Du hast mit deiner Aussage wahrscheinlich Recht aber ob die Durchsuchung nun 0,2ms oder 0,68ms dauert ist total egal, WENN es sich um einmalige Verwendung und nicht stumpfes loopen handelt.

Originally Posted by dowhile

* Deswegen ist das mögliche Einsatzgebiet stark beschränkt (keine größere Datenmenge, kein low-level Code der öfters aufgerufen wird, ...)

Ergibt keinen Sinn, spezifiziere das bitte.

Originally Posted by dowhile

Mkay. Hast du schonmal über einen beruflichen Werdegang bei Sun nachgedacht? Die Typen die die Java-API schreiben brauchen Leute wie dich!

Ich schlage dann grundsätzlich immer zwei Versionen der Methoden vor:

* eqauls_normal()
* equals_slowAndLongButKindaEasyToUnderstand()

Natürlich war die erste Aussage vollkommen überflüssig, darauf gehe ich deshalb erst gar nicht ein.

Ich schlage dann auch mal grundsätzlich zwei Versionen von Methoden vor:

equals_\s\w+[^0-2]-)\r[a-Zz-A]*[ + "s"()

und

string_between(str1, str2);


Ich weise übrigens nochmal darauf hin das es hier um die einmalige Verwendung (bzw. im kleineren Kontext) dieser Funktion geht. Nicht in denen, in der durch 50 Millionen Zeichen über eine Endlosschleife gelooped werden muss.