[php] hoe groter de source hoe slomer?

[Verwijderd]

Is het zo dat wanneer ik een hele site in eingelijk 1 .php file maak (met wat includes) dat deze dan veel slomer wordt dan wanneer ik een site maak die veel kleine onderdelen bevat..

of wordt zoiets wanneer veel gebruikt in het geheugen opgeslagen zodat de preformance eingelijk niet veel uitmaakt?

[Verwijderd]

Ik geloof dat de standaard PHP parser geen files in het geheugen opslaat, dus je hebt altijd te maken met de leestijd. Daarnaast heb je ook te maken met de parse tijd van een script zelf. Dat gaat altijd in minimaal 2 slagen, waarbij je bij de eerste slag altijd door het hele script heen gaat, bijv. om te checken of de syntax correct is. Met een grotere lap code duurt dit natuurlijk langer, ook al gebruik je maar een kwart van de code in de file.

HTH

[ Voor 0% gewijzigd door Verwijderd op 13-10-2002 13:45 . Reden: "De ik" ??? |:( ]

[DanceTrend]

Komt daar ook niet bij dat een grote php file gewoon groter is?

En html pagina laden van 100kb gaat ook langzamer dan eentje van 10kb..

[Verwijderd]

DanceTrend schreef op 13 oktober 2002 @ 13:35:
Komt daar ook niet bij dat een grote php file gewoon groter is?

En html pagina laden van 100kb gaat ook langzamer dan eentje van 10kb..

Uhm ... de vergelijking met een HTML file gaat op mbt tot het lezen van de file van de schijf door de webserver, hoewel een webserver vaak wel platte HTML files cached, en dat met PHP niet het geval is.

Wat jij waarschijnlijk bedoelt is de laadtijd door de webbrowser van een HTML pagina, maar dat gaat niet op. De grootte van een PHP file is namelijk onafhankelijk van de hoeveelheid output die het genereert.

[DanceTrend]

Ja oke dat is waar maar xtentic vraagt of het slomer wordt als je 1 grote file gebruikt.. Aannemend dat het een grote lap code is zal dit idd langzamer zijn dan als je bijvoorbeeld de code opdeelt in bestandjes mits je die ook niet allemaal tegelijk gaat gebruiken..

Correct me if im wrong...

[Verwijderd]

Wanneer je includes icm if statements gebruikt zal de parser sommige bestanden niet inlezen wanneer deze niet nodig zijn. Dit scheelt dus in de leestijd...

[De-Fault]

DanceTrend schreef op 13 oktober 2002 @ 13:42:
Ja oke dat is waar maar xtentic vraagt of het slomer wordt als je 1 grote file gebruikt.. Aannemend dat het een grote lap code is zal dit idd langzamer zijn dan als je bijvoorbeeld de code opdeelt in bestandjes mits je die ook niet allemaal tegelijk gaat gebruiken..

Correct me if im wrong...

Statistisch gezien heb je gelijk, maar die verschillen zijn verwaarloosbaar, zoek maar eens in php op parsetime enzo, zijn artikelen over geschreven.

[Zoijar]

Ik gebruik dit als factory:

PHP:

    function &factory($classname) {
        $classpath = 'class/'.$classname.'.class.php';

        if (file_exists($classpath)) {
            require_once($classpath);
            $obj = &new $classname($this->pass);
            return $obj;
        } else return false;
    }

Als het script dan een bepaalde class niet nodig blijkt te hebben (bv een exception, of een log ofzo) dan wordt die ook niet included.

[Erikie]

Jup, lijkt me logisch dat het trager wordt ja..

Je kunt beter veel includes maken, en deze te selecteren door een case functie. (soort if/else). Dan laadt ie alleen de php modules (of scripts) die je daadwerkelijk nodig hebt.

Je moet eens voor de gein zoeken naar fusebox, als je via die methodologie werkt, zul je merken dat je maar vanuit 1 pagina werkt, nl de index.php (of cfm of asp whatever).. check www.fusebox.org (spam!)

Ik ben er nu ook mee bezig. Het lijkt te werken, maar het is een hele klus om het onder de knie te krijgen.. mischien heb je er wat aan, zoniet, sla dit stuk maar lekker over ..

[chem]

React heeft precies last van hetzelfde probleem. Door grote en meerdere classes wordt het hele product langzaam.
Daarom hebben we in 1e instantie een 'basic' en 'advanced' class gemaakt van alle classes, zodat de base-classes klein bleven.
Aangezien dit goed hielp hebben we een disector geschreven, die dmv een configuratie file per-actie (list_messages, delete_topic etc.) 1 file wegschrijft met alleen de classes en daarvan alleen de functies die nodig zijn voor die speficieke actie.
Dat levert dan zo'n 40-50 files op die vv door Zend gaan.

Voordeel: je source blijft intakt, en je hoeft niet iets te 'doen' om te testen.
Nadeel: je config file voor de disector moet altijd up to date zijn als je 'productie' gaat, anders krijg je missende functies

[Gerwin]

Wat is een beetje een redelijke parstijd? Ik zit altijd op bijna 1 seconde, dat is toch erg veel?

[martinvw]

Gebruik je dan niet de verkeerde functie?
Er is er één voor seconde, maar ook één voor miliseconden?

[creative8500]

Gerwin schreef op 13 oktober 2002 @ 17:47:
Wat is een beetje een redelijke parstijd? Ik zit altijd op bijna 1 seconde, dat is toch erg veel?

Het kan ook zijn dat je een érg langzame server hebt.

[Verwijderd]

Sla fusebox zowiezo maar over. Het is de bedoeling dat je volgens deze methodiek een overzichtelijke structuur krijgt in je source. Het tegenovergestelde krijg je in mijn ogen.

[martinvw]

creative8500 schreef op 13 oktober 2002 @ 20:44:
[...]

Het kan ook zijn dat je een érg langzame server hebt.

Altijd op één seconde vind ik zo ie zo erg sterk

[Gerwin]

M4rt1nvW schreef op 13 oktober 2002 @ 20:59:
[...]

Altijd op één seconde vind ik zo ie zo erg sterk

Niet altijd precies, het zit altijd rond de 1 seconde meer erboven dan eronder...

[Rense Klinkenberg]

Op zich is het natuurlijk logisch dat de execution time omhoog gaat als je source code groter wordt. Php moet nl. bij elke request meer code valideren, meer code omzetten naar php's interne code en vervolgens dus ook meer code uitvoeren.

Dit probleem kan oa. opgelost worden met zogenaamde accelerators. De Zend accelerator is zo'n accelerator, die gemaakt is door de makers van php, zodat ze er ook nog een beetje geld aan kunnen verdienen. De Zend accelerator bewaard de gecompileerde versies van de sourcecode in het geheugen, zodat de code niet meer bij elke request gevalideerd en omgezet hoeft te worden.

Een andere zeer goede accelerator is php-accelerator. Deze is gratis en levert bijna dezelfde perfomance als de zend accelerator. Het idee achter php-accelerator is hetzelfde als de zend cache.

[TwoR]

Tja ik hou de source altijd kort en maak meerdere pagina's in mijn ogen gaat at sneller.

[drm]

Zoijar:
Ik gebruik dit als factory:

PHP:

    function &factory($classname) {
        $classpath = 'class/'.$classname.'.class.php';

        if (file_exists($classpath)) {
            require_once($classpath);
            $obj = &new $classname($this->pass);
            return $obj;
        } else return false;
    }

Als het script dan een bepaalde class niet nodig blijkt te hebben (bv een exception, of een log ofzo) dan wordt die ook niet included.

Uitermate handig

[Nielsz]

drm schreef op 14 oktober 2002 @ 16:09:

[...]

Uitermate handig

idd

En verder moet je gewoon geen grote sites bouwen, dan heb je er ook geen problemen mee

[Verwijderd]

ik gebruik ook includes dus.

index.php?id=bla

PHP:

<?If (isset($_GET['id']))
include ($_GET['id'] . ".inc");
Else
include("home.inc");?>

[drm]

unknownjim:
ik gebruik ook includes dus.

index.php?id=bla

PHP:

<?If (isset($_GET['id']))
include ($_GET['id'] . ".inc");
Else
include("home.inc");?>

_{zoute hacker}
Hmm interessant ...
index.php?id=http://www.mijndomein.com/showsource.php

of...

_{zoute hacker}
wat staat er achter 'id' ?
hmm, sjaak,
even kijken of http://www.jouwdomein.com/sjaak.inc wel geparsed wordt.

get the hint?

[Verwijderd]

Maar includen van een andere server werkt toch niet?

[drm]

samba:
Maar includen van een andere server werkt toch niet?

_{PHP Manual / include}
If "URL fopen wrappers" are enabled in PHP (which they are in the default configuration), you can specify the file to be included using an URL (via HTTP or other supported wrapper - see Appendix I for a list of protocols) instead of a local pathname. If the target server interprets the target file as PHP code, variables may be passed to the included file using an URL request string as used with HTTP GET. This is not strictly speaking the same thing as including the file and having it inherit the parent file's variable scope; the script is actually being run on the remote server and the result is then being included into the local script.

Als mijn "showsource.php" dus text output geeft die PHP code bevat ben je de beer. (i.e. als je dus allow_url_fopen aan hebt staan, wat volgens mij default het geval is).

[Gerwin]

drm schreef op 14 oktober 2002 @ 16:33:

[...]


[...]

of...

[...]


get the hint?

Dat is niet handig nee. een php code met wachtwoorden etc laten eindigen op een inc extentie.

Wat ik me wel afvraag is dat als iets niet IF is bijvoorbeeld dan word de code achter de IF toch niet geparced ofwel?