[PHP] Maximale recursiediepte?

[Kaastosti]

Ik ben wat aant spelen met php, klein functie'tje geschreven om tabe-in-tabel-in..etc te tekenen. Niet nuttig, maar wel lollig Nou komt ie maximaal tot 27. Bij een diepte van 28 krijg ik range 1-28 te zien ipv 0-27. Schieten we natuurlijk niets mee op

Ik vroeg me af of dat aan php ligt (lees: ergens in php.ini vastgelegde diepte), wat ik niet verwacht, ligt het aan html dattie maar 27 tables kan nesten

code:

function maaktabel($aantal){
    if($aantal < 1 ){
        echo $aantal;
        die();
    }
    echo $aantal;
    echo "<table border='1' width='95%' height='95%' align='center'><tr><td>&nbsp;";
    maaktabel($aantal-1);
    echo "</td></tr></table>";
}

maaktabel(10);

[.oisyn]

Kun je toch simpelweg controleren door de html niet te kijken in je browser maar in een text-editor

[Kaastosti]

Hmm jah het was te simpel he hij gaat idd bij de source wel gewoon door met tekenen.. ligt dus aan een limiet in html

[mbravenboer]

Het lijkt mij eerder dat er een beperking zit op het aantal stack-frames. Je checkt bij zoiets dus niet het aantal geneste tabellen (waarvan PHP helemaal geen kennis heeft), maar de toegestane recursie diepte voor een bepaalde methode. Die is in ieder geval groter dan 28 (hoop ik).

[.oisyn]

eerder een limiet in je browser
(ps: IE loopt hier keihard vast met 30 geneste tabellen )

[mbravenboer]

Kaastosti: ligt dus aan een limiet in html

Waarschijnlijk eerder de browser. Of er in XHTML een limiet is kan je in de standaard nagaan .

edit: traag .

[ Voor 6% gewijzigd door mbravenboer op 13-03-2003 15:26 ]

[Kaastosti]

Inderdaad dat kan natuurlijk ook nog. Eens kijken hoe het met andere browsers zit

[Verwijderd]

Ik denk dat het wel een uitzonderlijke situatie is als je überhaupt tabellen moet nesten (laat staan op meerdere niveau's), als je je netjes aan de specificaties en vooral doelstellingen van HTML houdt, en dus HTML op de juiste manier gebruikt.

[Kaastosti]

Tabellen nestelen gebeurd heeeeeeel veel, vooral als er met template engines gewerkt wordt. Een diepte van 28 is misschien wat te erg, maar diepte 3 komt wel vaak voor hoor

[Verwijderd]

Ik bedoel te zeggen dat het helemaal niet veel hóórt te gebeuren

[Kaastosti]

lol eigenlijk niet, maar de realiteit is anders... ik zit nou in m'n eerste week stage bij een webdesign-bedrijf en ik sta versteld van de kunsten die hier uit worden gehaald om het allemaal maar mooi en strak te krijgen

[ShadowrunR]

Leuk zo'n testscriptjes, kun je leuke dingen mee doen

Kaastosti schreef op 13 March 2003 @ 15:50:
lol eigenlijk niet, maar de realiteit is anders... ik zit nou in m'n eerste week stage bij een webdesign-bedrijf en ik sta versteld van de kunsten die hier uit worden gehaald om het allemaal maar mooi en strak te krijgen

Weet je direct wat voor kunstenaars webdesigners wel niet zijn

[Kaastosti]

Weet je wat pas erg is... ze maken een heeeele zooi templates (stuk of 20), waarvan er dan maar 1 uitgekozen wordt. Dus 19 stuks voor noppes gemaakt wordt je toch spontaan depri van? Maar goed... we raken off-topic... IE heeft dus idd een max tabeldiepte van 28.

[Glimi]

mbravenboer schreef op 13 maart 2003 @ 15:25:
Het lijkt mij eerder dat er een beperking zit op het aantal stack-frames. Je checkt bij zoiets dus niet het aantal geneste tabellen (waarvan PHP helemaal geen kennis heeft), maar de toegestane recursie diepte voor een bepaalde methode. Die is in ieder geval groter dan 28 (hoop ik).

Nou dat ligt eraan Als het maar niet over de maximum memory size van PHP heen gaat (standaard 8 meg)

Nu heb ik zo'n beetje de meest minieme functie (foutief) recursief gemaakt

PHP:

<?php

    function recTest( $n ) {

        echo( $n . '\n' );
        recTest( $n +1 );
    }

    set_time_limit( 0 );
    recTest( 1 );
?>

En daar kon ik dus met die 8mb 52723 maal van de bovenstaande functie gebruik maken.

Dat betekend dus dat elke call ( ik neem aan gelijk voor elke call, aangezien het niet complexer wordt ) zo'n 8388608 bytes / 52723 keer ~= 160 bytes per call gealloceerd worden. Aangezien een int meestal (aanname!!) 32 bits ( dus 4 bytes ) en een adres van een functie meestal een 32 bits adres is ( ook 4 bytes ) zouden er 40(!) functieadressen en integers geinitialiseerd worden per call

Nu verdonkermaan ik natuurlijk de overheadkosten van het initialiseren van PHP, maar kan dat zoveel schelen?? Maw waar gaat deze berekening op fout

[Kaastosti]

Nieuwe icon glim?
Ik heb overigens die max mem size in de ini al verhoogd met het idee dat het daar aan zou kunnen liggen. Het maakt niet uit wat ik allemaal verhoog, die limiet blijft er. Bij andere recursieve functies zoals die van jou kun je uiteraard nog verder komen (wat ook wel verwacht mocht worden), maar het ging dan ook om het maximaal aantal tabellen wat genest wordt.

[.oisyn]

Let erop dat php niet wordt gecompileerd naar machinecode, volgens mij nog niet eens bytecode. Het loopt dus direct door de interpreter, en een functiecall voegt dus niet alleen een functieaddress + int aan de stack toe (op x86 cpu's is het overigens ook niet alleen dit, maar komen er nog een paar ints extra aan stack frame e.d. bij)

Je moet het zeg maar zo zien:

Java:

class Function
{
    // ...
    void run ()
    {
         foreach (statement in statements)
             statement.run ();
    }
}

class Statement
{
}

class FunctionCallStatement extends Statement
{
    void run ()
    {
        var args[];
        foreach (expr as expressions)
        {
            args.add (expr.evaluate ());
        }
        function.call (args);   // roept Function.run () weer aan
    }
}

je zit dus midden in de interpreter, en die functies met hun locale parameters komen allemaal op de stack te staan.

[crisp]

Glimi schreef op 13 March 2003 @ 17:49:
[...]

PHP:

<?php

    function recTest( $n ) {

        echo( $n . '\n' );
        recTest( $n +1 );
    }

    set_time_limit( 0 );
    recTest( 1 );
?>

[...]

Glimi: jouw functie crashed mijn PHP (4.3 onder IIS CGI mode) al na 462 aanroepen.
Functies die van meer variabelen (al dan niet global) gebruik maken crashen bij mij al veel eerder (vaak ook tussen de 25 en 30 calls), en dan zit ik nog lang niet aan mijn memory limit van 32MB.
Lijkt me dus wel degelijk een bug in PHP...

[ Voor 44% gewijzigd door crisp op 13-03-2003 22:52 ]