jumini: Wie neugierig ist eigentlich der Parser?

Hallo,

Kurz und knapp: Wie sinnvoll schließt der Parser Codeblöcke aus, die in der aktuellen Laufzeit nicht benötigt werden.

Also beispielsweise folgendes Szenario:

<?php  
switch('parseMe'){  
 case 'parseMeNot':  
  // sehr viel code  
 break;  
 case 'parseMe':  
  // ..  
 break;  
}

Dass der eigentliche Inhalt des ersten Case nicht verarbeitet wird, ist klar. Muss das PHP-Modul jedoch den Text interpretieren oder wird das direkt ausgeschlossen?

Gruß,
jumini

  1. Hi,

    Dass der eigentliche Inhalt des ersten Case nicht verarbeitet wird, ist klar. Muss das PHP-Modul jedoch den Text interpretieren oder wird das direkt ausgeschlossen?

    Der Parser analysiert die Syntax, und das noch vor der eigentlichen Ausführung des Codes. Beantwortet das deine Frage?

    MfG ChrisB

    --
    RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?
    1. Der Parser analysiert die Syntax, und das noch vor der eigentlichen Ausführung des Codes. Beantwortet das deine Frage?

      Ja, also macht es resultierend tatsächlich mehr Sinn den Code in einzelne Dateien aufzuteilen und zu inkludieren - mein Fazit: die Inkludierung benötigt zwar Zeit, spart bei großen Dateien aber die Zeit der Syntaxanalyse ein. (Das war der Hintergrund meiner Frage)

      Sollte das nicht völliger Quatsch sein, weiß ich nun bescheid.

      Danke & Gruß

      1. Hi,

        wenn wir hier wieder mal nur über Mikro-Optimierung reden, sollten wir am besten gar nicht darüber reden :-) - das gilt bei PHP pauschal erst mal immer.

        Ja, also macht es resultierend tatsächlich mehr Sinn den Code in einzelne Dateien aufzuteilen und zu inkludieren - mein Fazit: die Inkludierung benötigt zwar Zeit, spart bei großen Dateien aber die Zeit der Syntaxanalyse ein. (Das war der Hintergrund meiner Frage)

        Diese „Syntaxanalyse“ braucht nur minimal Zeit - die paar Millisekunden bemerkt im Web kein Mensch.

        Wie du Code auf Dateien aufteilst oder ggf. auch nicht, solltest du eher davon abhängig machen, wie (un)übersichtlich das System dadurch aus Sicht des Programmierers wird.

        Wenn der Zeitaufwand zum Parsen des Codes wirklich irgendwann eine relevante Größe darstellen sollte - dann wären zur Optimierung an dieser Stelle Bytecode-Compiler die angebrachtere Option.

        MfG ChrisB

        --
        RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?
        1. Diese „Syntaxanalyse“ braucht nur minimal Zeit - die paar Millisekunden bemerkt im Web kein Mensch.

          Meine "bemerkt schon kein Mensch"-Liste ist leider schon voll :(

          Wie du Code auf Dateien aufteilst oder ggf. auch nicht, solltest du eher davon abhängig machen, wie (un)übersichtlich das System dadurch aus Sicht des Programmierers wird.

          Ganz pragmatisch: ich habe beide Optionen und möchte die schneller wissen. Rechtfertigt das meine Frage? ;)

          Wenn der Zeitaufwand zum Parsen des Codes wirklich irgendwann eine relevante Größe darstellen sollte - dann wären zur Optimierung an dieser Stelle Bytecode-Compiler die angebrachtere Option.

          Und bis dahin will ich genau wissen wie mein PHP-Parser arbeitet, damit ich sogar die letzte http://de.wikipedia.org/wiki/Vorsätze_für_Maßeinheiten#SI-Pr.C3.A4fixe-Sekunde ausschöpfen kann, über welche ich mir im Klaren bin.
          Nennt mich spießig.

          Gruß,
          jumini

          1. Hi there,

            Nennt mich spießig.

            Ich nenn' Dich unökonomisch. In der Zeit, in der Du Dir diese nutzlosen Gedanken machst, hättest Du schon etwas Sinnvolles programmieren können...

      2. [latex]Mae  govannen![/latex]

        Ja, also macht es resultierend tatsächlich mehr Sinn den Code in einzelne Dateien aufzuteilen und zu inkludieren - mein Fazit: die Inkludierung benötigt zwar Zeit, spart bei großen Dateien aber die Zeit der Syntaxanalyse ein. (Das war der Hintergrund meiner Frage)

        Wie kommst du darauf, daß der Parser den includierten Code nicht prüfen würde? Ich weiß nicht, ob das bereits beim Syntaxcheck geschieht (d.h. die Datei dort bereits eingelesen und geprüft wird) oder erst beim Interpretieren, so oder so verschiebt sich lediglich der Zeitpunkt um ein paar Zeiteinheiten.

        Stur lächeln und winken, Männer!
        Kai

        --
        Dank Hixies Idiotenbande geschieht grade eben wieder ein Umdenken
        in Richtung "Mess up the Web".(suit)
        SelfHTML-Forum-Stylesheet
        1. Wie kommst du darauf, daß der Parser den includierten Code nicht prüfen würde?

          Ich bin mir sicher, dass der Parser inkludierten Code erst nach dem tatsächlichen Aufruf von include() bzw require() verarbeitet, da dieser ja auch dynamisch auftreten kann, sprich der Parser ggf. erst nach der Ausfürhung des vorangehenden Codes weiß, welche Datei tatsächlich eingebunden werden soll.

          Gruß

          1. Hi,

            Wie kommst du darauf, daß der Parser den includierten Code nicht prüfen würde?

            Ich bin mir sicher, dass der Parser inkludierten Code erst nach dem tatsächlichen Aufruf von include() bzw require() verarbeitet, da dieser ja auch dynamisch auftreten kann, sprich der Parser ggf. erst nach der Ausfürhung des vorangehenden Codes weiß, welche Datei tatsächlich eingebunden werden soll.

            Genau, das include kann ja bspw. auch von einer Bedingung abhängig sein - simpler Test:

            Datei parser_include_error.php:

            <?php  
             foobar
            
            • gibt beim direkten Aufruf selbstverständlich einen parse error,

            Parse error: parse error in [...]/parser_include_error.php on line 2

            Datei parser_include.php:

            <?php  
            if(1) include 'parser_include_error.php';
            
            • ergibt bei Aufruf genau die gleiche Fehlermeldung.

            Machen wir aus der 1 eine 0, damit die Bedingung nicht mehr zutrifft - kein Fehler mehr.

            MfG ChrisB

            --
            RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?
  2. Hi,

    <?php

    switch('parseMe'){
    case 'parseMeNot':
      // sehr viel code
    break;
    case 'parseMe':
      // ..
    break;
    }

    
    >   
    > Dass der eigentliche Inhalt des ersten Case nicht verarbeitet wird, ist klar. Muss das PHP-Modul jedoch den Text interpretieren  
      
    natürlich muß der Parser sich den ersten case komplett angucken. Woher soll er sonst wissen, wo der tatsächlich zu Ende ist?  
      
    cu,  
    Andreas
    
    -- 
    [Warum nennt sich Andreas hier MudGuard?](http://MudGuard.de/)  
    [O o ostern ...](http://ostereier.andreas-waechter.de/)  
      
    Fachfragen per Mail sind frech, werden ignoriert. Das Forum existiert.  
    
    
    1. natürlich muß der Parser sich den ersten case komplett angucken. Woher soll er sonst wissen, wo der tatsächlich zu Ende ist?

      Indem er einfach nach dem nächsten "break" ausschaut hält. Ach verdammt, da hast du mich erwischt, das nächste break muss ja nicht zwangsweise das richtige sein. Ich denke damit ist die Frage beantwortet :)

      Gruß

      1. Hi,

        natürlich muß der Parser sich den ersten case komplett angucken. Woher soll er sonst wissen, wo der tatsächlich zu Ende ist?

        Indem er einfach nach dem nächsten "break" ausschaut hält. Ach verdammt, da hast du mich erwischt, das nächste break muss ja nicht zwangsweise das richtige sein.

        Das nächste Auftauchen der Zeichenkette "break" muss nicht mal ein break sein - es kann auch
        // break
        oder
        /* break */
        sein.

        MfG ChrisB

        --
        RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?
      2. Hi,

        natürlich muß der Parser sich den ersten case komplett angucken. Woher soll er sonst wissen, wo der tatsächlich zu Ende ist?

        Indem er einfach nach dem nächsten "break" ausschaut hält. Ach verdammt, da hast du mich erwischt, das nächste break muss ja nicht zwangsweise das richtige sein.

        Das nächste break muß nicht mal existieren.

        cu,
        Andreas

        --
        Warum nennt sich Andreas hier MudGuard?
        O o ostern ...
        Fachfragen per Mail sind frech, werden ignoriert. Das Forum existiert.