[Jann Hendrik]

ah.... array_slice() kannte ich nicht...

Zitat von Basti

Wenn eine Funktion einen boolschen Wert zurückgibt, musst du in deinen IF-Klauseln nicht prüfen, ob das Ergebnis === true ist:

das weiß ich wohl - aber ich finde es trotzdem schöner mit === true zu arbeiten.

btw: die Angabe type habe ich nun so übernommen:

PHP-Code:

in_array($arrayParameter['type'], array('1', 'i', 'I', 'a', 'A')) 


das gefällt mir durchaus.


derzeit sieht der case für list so aus:

PHP-Code:

          case 'list':
            $stringType = '';
            $start      = '';

            if(count ($arrayParameter) == 0 OR array_key_exists ('__INIT__', $arrayParameter) === FALSE)
            {
              $list     = 'ul';
            }
            else
            {
              $list     = 'ol';

              if(array_key_exists('type', $arrayParameter) === TRUE
                 &&
                 in_array($arrayParameter['type'], array('1', 'i', 'I', 'a', 'A')))
              {
                $stringType = ' type="'.$arrayParameter['type'].'"';
              }

              if(is_numeric($arrayParameter['__INIT__']))
              {
                $start = ' start="'.ceil($arrayParameter['__INIT__']).'"';
              }
              else
              {
                $start = ' start="1"';
              }
            }

            $stringText = '<'
                          .$list
                          .$start
                          .$stringType
                          .'><li>'
                          .implode(array_slice(explode('[*]', $stringText), 1), '</li><li>')
                          .'</li></'
                          .$list
                          .'>';
            unset($stringType, $start, $list);
            break; 


[MrNiceGuy]

Zitat von $traight-$hoota

autsch...

Also noch sinnfreier können Reguläre Ausdrücke ja fast nicht mehr angewandt werden... sry, aber ist so

Ist es wirklich so? Meines Wissens nach werden Reguläre Ausdrücke dazu genutzt, bestimtme Zeichenketten (oder eben auch einzelne Zeichen) in einem Text zu suchen und zu finden. Ergo ist es wohl eher Geschmackssache, denn Sinnfreiheit, die hier eine Rolle spielt.

Zitat von $traight-$hoota

wie wäre es denn in diesem Fall einfach mit nem schlanken in_array?

PHP-Code:

in_array($arrayParameter['type'], array('1', 'i', 'I', 'a', 'A')) 


Mit strtolower könnte man zwar auch die Großbuchstaben im Array sparen, aber das wäre bei dieser kleinen Menge wohl nur lansamer.

Alternativ wäre auch ein z.B. ein solcher switch um einiges schneller als ein regex:

PHP-Code:

switch(strtolower($arrayParameter['type'])){
     case '1':
     case 'i':
     case 'a':
     $stringType = ' type="'.$arrayParameter['type'].'"';
     break;
} 


Außerdem könntest du das ganze noch ein bischen weiter optimieren, indem du das str_replace vor der if-abfrage, also bevor die umgebebenden listen-tags generiert werden, ausführst. Diese Strings würden ja sonst umsonst durchsucht.
Und du solltest überprüfen, ob $arrayParameter['__INIT__'] eine zahl ist um kein fehlerhaftes HTML zu erzeugen.

Ich habe mir mal eben die Mühe gemacht zu testen, was wirklich schneller ist und bin dabei zu einem erstaunlichen Ergebnis gekommen:

Ich habe ein kleines Benchmark-Script geschrieben, mit dem ich jeweils pro Aufruf eine Million Durchläufe der entsprechenden Zeile teste. Für einen einigermaßen guten Durchschnittswert habe ich 10 mal das selbe Script aufgerufen:

RegEx:
Kürzester Durchlauf: 0,95406604
Längster Durchlauf: 0,97809410
Durchnittliche Zeit: 0,96451592

switch mit strtolower:
Kürzester Durchlauf: 0,93610907
Längster Durchlauf: 0,95748019
Durchnittliche Zeit: 0,94841073

switch ohne strtolower:
Kürzester Durchlauf: 0,53370285
Längster Durchlauf: 0,56261992
Durchnittliche Zeit: 0,54376390

in_array:
Kürzester Durchlauf: 1,93268394
Längster Durchlauf: 1,95844913
Durchnittliche Zeit: 1,94565451

So, wie man sieht ist der RegEx garnicht soooooo langsam, wie du es hier darstellen wolltest. Hingegen ist deine Lösung bzgl in_array() weder schlanker, noch performanter, als der RegEx UND meiner Meinung nach auch noch sinnfreier, als ein RegEx - das ist aber wie gesagt Geschmackssache, ich wollte nur das Wort "Sinnfrei" nochmal einbauen . Die einzig sinnvolle Alternative bzgl. Performance bietet ein switch, allerdings ohne strtolower(). Diese Lösung ist hingegen alles Andere als schlank. Für mich bleibt also eigentlich nur ein Fazit: Wenn man es Schlank UND Performant haben möchte, sollte man einen RegEx benutzen.

Btw noch ein prozentualer Vergleich der einzelnen Möglichkeiten:

switch ohne strtolower() : 100%
switch mit strtolower() : ~174,42%
regulärer Ausdruck : ~177,38%
in_array() : ~357,81%

Der RegEx ist übrigens gerade mal ca. 1,7% langsamer, als der switch mit strtolower() (wenn der switch mit 100% veranschlagt wird).

Soviel dazu.

[Jann Hendrik]

sinnfrei sinnfrei....

nein - natürlich nicht. Danke dir für deine Mühe!
Das erstaunt mich! Ich hätte gedacht, dass der RegEx schlechter abscheiden würde!

[$traight-$hoota]

Also das finde ich wirklich sehr erstaunlich
Die Werte für switch und Regex entsprechen so in etwa meinen Vorstellungen. Dass aber in_array so aufwändig ist, hätte ich wirklich nicht gedacht... Das macht ja eigentlich auch nicht mehr als folgender Code, aber im Maschienencode, und hat eine lineare Ausführungszeit:

PHP-Code:

function in_array($needle, $haystack) {
    foreach($haystack as $needle) {
        if($needle == $haystack)
            return true;
    }
    return false;
} 


Wie das mehr als doppelt so lange dauern kann wie eine komplette regex-initialisierung und -match, ist mir unverständlich...

Ok, hab mir ma die Kommentare auf php.net angesehen:

Zitat von melissa at hotmail dot com

With a bit of testing I've found this function to be quite in-efficient...

To demonstrate... I tested 30000 lookups in a consistant environment. Using an internal stopwatch function I got approximate time of over 1.5 mins using the in_array function.

However, using an associative array this time was reduced to less than 1 second...

In short... Its probably not a good idea to use in_array on arrays bigger than a couple of thousand...

The growth is exponential...

Auch wenn die exponentielle Ausführungszeit bei dieser geringen Menge an Elementen kein Problem sein sollte, ist in_array also doch total ineffizient und ein associatives Array wäre weitaus schneller, weil dann mit Hashes gearbeitet wird.
Man lernt immer wieder was neues... auch wenns irgendwie ziemlich verrückt ist
also das sollte dann wohl um einiges schneller sein:

PHP-Code:

$arrayTypes = array('i' => 0, 'I' => 0, 'a' => 0, 'A' => 0, '1' => 0);
if(isset($arrayTypes[$stringType])) { 


oder halt doch wieder die einzelbedingungen, die sollten in der ausführung so in etwa bei dem switch ohne strtolower liegen.

Zitat von MrNiceGuy

Ist es wirklich so? Meines Wissens nach werden Reguläre Ausdrücke dazu genutzt, bestimtme Zeichenketten (oder eben auch einzelne Zeichen) in einem Text zu suchen und zu finden.

Ja, genau dazu sind Regex eigentlich da und nicht um zu überprüfen, ob ein einzelnes (!) Zeichen einem von fünf vordefinierten entspricht. Unabhängig von dem Ergebnis des Geschwindigkeitstests ist das wie mit Kanonen auf Spatzen zu schießen...

[Jann Hendrik]

Zitat von $traight-$hoota

ist das wie mit Kanonen auf Spatzen zu schießen...

Wobei diese Kanonen wirklich erstaunlich gut treffen!

[MrNiceGuy]

@$traight-$hoota: Ja, deine Schätzung kommt hin, der Durchschnittswert liegt bei ca. 0,54, also etwa gleichschnell wie switch ohne strtolower.

Zu den RegEx selber muss ich sagen, dass ich da nicht deiner Meinung bin, denn letztendlich suche ich auch mit dem obigen RegEx einen Text - und finde ihn. Ob es sich dabei um komplexe BBCodes handelt oder schlicht um ein einzelnes Zeichen, spielt dabei keine Rolle. Und dass es performancemäßig keine große Rolle spielt zeigen die Benchmarks. Die Test-Datei sieht übrigens so aus:

PHP-Code:

<?php
set_time_limit (0);

function functionCalculateTimeDifference ($stringTimeStart,
                                          $stringTimeStop
                                          )
{
  $arrayTimeStart = explode (' ',
                             $stringTimeStart
                             );

  $arrayTimeStop = explode (' ',
                            $stringTimeStop
                            );

  $floatTimeStart = floatval ($arrayTimeStart[0]) + floatval ($arrayTimeStart[1]);
  $floatTimeStop  = floatval ($arrayTimeStop[0]) + floatval ($arrayTimeStop[1]);

  return number_format ($floatTimeStop - $floatTimeStart,
                        8,
                        ',',
                        '.'
                        );
}

$stringTimeStart = microtime ();

for ($integerCount = 0;
     $integerCount < 1000000; // 1.000.000
     $integerCount++
     )
{
  // Hier den Code rein...
}

$stringTimeStop = microtime ();

echo functionCalculateTimeDifference ($stringTimeStart,
                                      $stringTimeStop
                                      );
?>

Habe entsprechend die Codes dann dort eingefügt:

PHP-Code:

preg_match ('°^[1ia]$°i', 'a'); 


Ich habe die Variable durch 'a' ersetzt, da die Variable ansich ja nicht definiert ist. Ich habe das bei allen Variablen ersetzt, um ein möglichst einheitliches Ergebnis zu erhalten.

PHP-Code:

in_array('a', array('1', 'i', 'I', 'a', 'A')); 


PHP-Code:

switch (strtolower ('a'))
{
  case '1':
  case 'i':
  case 'a':
  $stringType = ' type="'.$arrayParameter['type'].'"';
  break;
} 


PHP-Code:

switch (strtolower ('a'))
{
  case '1':
  case 'i':
  case 'I':
  case 'a':
  case 'A':
  $stringType = ' type="'.$arrayParameter['type'].'"';
  break;
} 


Ich habe heute allerdings nochmal drüber nachgedacht und festgestellt, dass ich einen kleinen Fehler gemacht habe, der eventuell dem Einen oder Anderen auch aufgefallen ist: Ich habe die Array-Definition im Funktionsaufruf dringehabt. Wenn man das 5-elementige Array vor der Schleife ein Mal definiert und dann nurnoch die Variable an in_array übergibt sieht das Ergebnis ganz anders aus:

Kleinste Dauer: 1,03227711
Größte Dauer: 1,05588198
Mittelwert: 1,04703190

Auch hier habe ich wieder 10 Scriptdurchläufe mit je einer Million Schleifendurchläufe gemessen. Es ist immernoch langsamer, als der RegEx, allerdings doch nicht so krass, wie ich es am Anfang gemessen hatte. Bei deutlich mehr Elementen wird sich das aber wohl doch wieder ins weit negativere verschieben, so wie du es schon zitiert hast.

Ich bleibe halt dabei, dass es mit dem RegEx reine Geschmackssache ist und wohl auch bleiben wird. Um die schnellstmögliche Methode zu benutzen müsste man allerdings den Switch realisieren oder eben mit assoziativen Arrays arbeiten. Das bleibt einem selbst überlassen, die kürzeste Fassung bleibt aber wohl dennoch der RegEx. Es ist also an Jann sich zu entscheiden.

Btw: Ich werde auch nochmal einen Test mit array_key_exists() anstellen, mal schauen, wie die sich in dieser Situation schlägt

[MrNiceGuy]

Hmm... interessant, jetzt auf ein Mal sagt mir mein Script, dass die isset()-Variante folgende Werte aufweist:

Min: 0,18206596
Max: 0,21433187
Avg: 0,20084927

Ich hatte allerdings auch bevor ich die Werte nochmal protokolliert hatte Werte um 0,16 und 0,17. Scheinbar waren die ersten paar Durchläufe aus anderen Gründen etwas langsamer!? Nun gut, das oben sind jedenfalls jetzt Ergebnisse nach 10 Scriptaufrufen usw, ihr wisst ja bescheid.

Für array_key_exists liegen die Ergebnisse auch vor:

Min: 0,51477981
Max: 0,55369115
Avg: 0,54045768

Mag sein, dass ich vorhin aus versehen mit array_key_exists() gemessen hatte und es fälschlicher Weise als isset() eingetragen hatte, sorry.

Die letzte Methode, die mir noch einfällt wäre dann ohne isset() direkt auf den Wert zuzugreifen:

Min: 0,19494700
Max: 0,22789097
Avg: 0,21544781

Diese Methode hat jedoch zum Nachteil, dass - je nach Konfiguration von PHP - ein Notice geschmissen wird, was natürlich eine unsaubere Methode wäre.

Meine Empfehlung nach den Tests ist nun also ganz klar zur isset-Variante mit vorher festgelegtem Array (notfalls halt als static-Array in der Klasse), da diese die Schnellste Abarbeitung mit sich bringt und die Übersichtlichkeit nicht so wahnsinnig einschränkt. Geht es jedoch nur darum den Code so klein wie möglich zu halten, würde meine Wahl auf den RegEx fallen, auch wenn dieser von manchen Leuten als sinnfrei erachtet wird -)), denn er bietet, wie ich finde, die beste Performance im Verhältnis zur Übersichtlichkeit.

[robo47]

Zitat von MrNiceGuy

So, wie man sieht ist der RegEx garnicht soooooo langsam, wie du es hier darstellen wolltest.

Das Problem an Benchmarks ist oftmals, dass man nicht weis, was wirklich im Hintergrund passiert (was PHP + seine Module machen) und genau der Fall liegt hier denke ich vor.

Regex werden unter gewissen Umständen bei PHP gecacht, heißt, wenn du sie X mal hintereinander direkt (in einem script) ausgeführt werden, wird das ganze zwar sehr schnell, aber es lässt keine Rückschluss darauf zu, wie schnell der Regex wirklich im produktiven Einsatz ist, wo eben nur 1 mal oder wenige mal innerhalb eines Scripts zum Einsatz kommt.

Die Infos hab ich von diesem Blogeintrag auf phpperformance.de.

Doch die Sache hat einen Haken: Kompilierte reguläre Ausdrücke werden pro Thread zwischengespeichert. Das ist für die mehrmalige Anwendung ganz nett, aber im Normalfall wird der Ausdruck genau 1x pro Seitenaufruf/Thread benötigt. Der Cache sitzt in der PCRE-Erweiterung und speichert pro Thread bis zu 4096 kompilierte Ausdrücke. Der Overhead ist also nur bei einem von 100.000 Durchläufen zu spüren.

[Basti]

Ihr habt nicht das Gefühl, dass die Performance-Flaschenhälse woanders liegen, als hier? Ich meine, ein BB-Code verändert sich dann, wenn sich jemand hinsetzt und einen Beitrag schreibt. Derjenige wird sicherlich Verzögerungen im Millisekundenbereich verkraften können. Da wäre dann eher die Frage, wie das Caching aussieht etc.

Ich weiß, ist hier nicht das Thema, aber auch in der Klasse gibt es sicherlich für die Performance gravierendere Entscheidungen, als dieses „ist das Zeichen eines von diesen 5?“

Basti

[$traight-$hoota]

Zitat von Basti

Ich weiß, ist hier nicht das Thema, aber auch in der Klasse gibt es sicherlich für die Performance gravierendere Entscheidungen, als dieses „ist das Zeichen eines von diesen 5?“

Sicherlich ist das für einen konkreten Fall absolut unwichtig, aber ich denke dennoch, dass hier ganz interessante ergebnisse rausgekommen sind, die ich - wie oben schon gesagt - nicht so erwartet hätte.
aber wie robo schon sagte, sind solche benchmarks nicht wirklich objektiv, da sie eben nicht die "echte" anwendung darstellen, sondern diese nur nachahmen.

[MrNiceGuy]

Benchmarks haben ja im Grunde auch nur eine Art Hinweischarakter. Ich kann demnächst nochmal einzelne Aufrufe mit dem RegEx testen, alelrdings kann es dann sein, dass das Ergebnis recht mau ausfällt da die Zeitspanne nicht wirklich groß ist und man dann selbst microtime() an die Grenze des messbaren kommt...

[Jann Hendrik]

Da ich gerade dabei bin an dem code-tag (wie er hier auch im Forum vorkommt) zu basteln nutze ich mal diesen thread.

--------

Alles könnte so schön sein. Ich füge einfach folgenden case hinzu:

          case 'code':
            $stringText = '&nbsp;</p><div style="margin:20px; margin-top:5px">
                 <div style="margin-bottom:2px">Code:</div><pre style="margin:0px; padding:6px; border:1px inset; width: 100%; height:80px; overflow:auto">'.$stringText.'</pre></div><p>&nbsp;';
            break;

und fertig. Nun - würde das so einfach funktioniert würde ich ja keine Frage stellen

Wenn ich dann Code wie diesen hier dort darstellen lassen will:

\documentclass[a4paper, 11pt]{scrartcl} 
\usepackage[ngerman]{babel}
\usepackage[T1]{fontenc}

\begin{document}
\section{Überschrift}
Hier nun ein Text
\end{document}

Dann wird genau nichts mehr angezeigt.

Hatz jmd. dazu eine Idee, wie man das vernünftig umsetzen kann?

Derzeit hülle ich den Inhalt noch in ein noparse-tag, aber das kann ja keine Lösung sein...

[MrNiceGuy]

Schreib mir bitte am WE oder so noch mal eine Mail, dann kann ich nach dem Problem mal schauen, aber momentan kann ich nicht ganz nachvollziehen, was mit dem String passiert, wenn du ihn nicht in noparse-Tags hängst...

[MrNiceGuy]

Manoman, das hat mich einige Zeit gekostet, den Fehler zu finden...

Also: Im Tutorial hatte ich folgenden RegEx dazu benutzt, um die rekursive Abfrage zu gestalten:

    $stringText = preg_replace_callback ('°\[(\w+)([^]]*)]((?:[^[]|\[(?!/?\1])|(?R))*)\[/\1]°',
                                         'functionBBCode',
                                         $stringText
                                         );

Diese Abfrage ist leider fehlerhaft und führt bei deinem Text - aus welchen genauen Gründen auch immer - zu einem Fehler. Da keine Fehlermeldung ausgegeben (und auch nicht in die Log-Datei eingetragen) wird, konnte ich leider nur durch probieren herausfinden, was geändert werden muss, damit es funktioniert. Die Lösung ist nicht so richtig elegant und warum das im Gegensatz zur ursprünglichen Methode funktioniert ist mir immernoch schleierhaft, aber egal:

    $stringText = preg_replace_callback ('°\[(\w+)((?:\s|=)(?:[^]]*))?]((?:[^[]|\[(?!/?\1])|(?R))*)\[/\1]°',
                                         'functionBBCode',
                                         $stringText
                                         );

So muss der neue RegEx aussehen, damit es funktioniert. Geändert wurde das "([^]]*)" in "((?:\s|=)(?:[^]]*))?". Wie auch immer, es hilft.

Ich werde gleich noch meinen Beitrag im Tutorial abändern und den Anhang auch verändern.

[Jann Hendrik]

Die Zeichensuppe - so möchte das mal bezeichnen - ist schon abgefahren. Ich steige da jedenfalls nicht mehr durch!

Dir auf jedenfall ein dickes Danke!