[PHP] include <=> file-grootte efficientie

Pagina: 1
Acties:

  • surfdude
  • Registratie: Maart 2000
  • Laatst online: 16-06 22:34
Kan iemand mij vertellen waar (het is misschien een beetje kort door de bocht, maar goed :)) de overgang in efficientie (snelheid) tussen bestandsgrootte en (de overhead van) het includen van een bestand ligt?
Of heeft iemand een linkje naar artikel hierover?

Het kan altijd mooier en beter...


  • Nielsz
  • Registratie: Maart 2001
  • Niet online
ach, zodra ik een functie opnieuw kan gebruiken dump ik 'm in een include. Heeft verder weinig met efficientie te maken bij mij.

  • Infinitive
  • Registratie: Maart 2001
  • Laatst online: 19-09 17:21
Ik heb de source van php gecheckt. In principe heeft het geen (merkbare) overhead, tenzij je een heleboel erg kleine files gaat includen (lees: de grootte van de files is veel kleiner dan php's readbuffersize).

PHP werkt in 2 fases, compilatie fase en executie fase. In de compilatie fase worden de php file gelezen en omgezet naar een interne-vorm (boomstructuur), wanneer php een include tegenkomt wordt deze ingelezen en "meegebakken". Nu is het wel zo dat als je erg veel kleine files hebt (zoals ik hierboven gezegt heb) dat php niet erg optimaal van zijn buffers gebruik maakt (dus relatief veel reads ten opzichte van de opdrachten die hij uit de files haalt), maar dat effect is te verwaarlozen.

putStr $ map (x -> chr $ round $ 21/2 * x^3 - 92 * x^2 + 503/2 * x - 105) [1..4]


  • surfdude
  • Registratie: Maart 2000
  • Laatst online: 16-06 22:34
Dat het qua PHP geen echte overhead geeft ok, maar ik dacht meer aan de aanroep van het bestand (via het OS) die gedaan moet worden en de hd seektime...

Het kan altijd mooier en beter...


  • Infinitive
  • Registratie: Maart 2001
  • Laatst online: 19-09 17:21
mwa, hd seektime is alleen van toepassing als je script veel uitgevoert worden en in dat geval bevinden heeft je OS die files toch al wel in cache staan.

putStr $ map (x -> chr $ round $ 21/2 * x^3 - 92 * x^2 + 503/2 * x - 105) [1..4]


  • MikeN
  • Registratie: April 2001
  • Laatst online: 18:15
Op maandag 10 september 2001 10:29 schreef surfude het volgende:
Dat het qua PHP geen echte overhead geeft ok, maar ik dacht meer aan de aanroep van het bestand (via het OS) die gedaan moet worden en de hd seektime...
Dan maakt het volgens mij niet uit of het in hetzelfde of in een ander bestand staat. Het moet altijd van de hd worden gehaald.

  • surfdude
  • Registratie: Maart 2000
  • Laatst online: 16-06 22:34
Op maandag 10 september 2001 10:31 schreef MikeN het volgende:

[..]

Dan maakt het volgens mij niet uit of het in hetzelfde of in een ander bestand staat. Het moet altijd van de hd worden gehaald.
PHP leest toch eerst het (even voor het gemak) php bestand en komt dan tegen dat het een andere moet includen. Dat is volgens mij toch echt een nieuwe hd actie (ipv. 1 read).

Niet dat ik anti include ben hoor (in tegendeel, nu ik aan een iets groter projectje werk, vind ik het juist erg praktisch ;)).

Maar die OS cache is hier waarschijnlijk idd. erg belangrijk.

Het kan altijd mooier en beter...


  • Infinitive
  • Registratie: Maart 2001
  • Laatst online: 19-09 17:21
Bedenk wel dat php niet in 1x de file leest, maar een x aantal bytes tegelijk (ik dacht 4KB ofzo). Als je dus allerlei files include van 3.99 KB en de OS heeft je file in z'n cache staan, dan maakt het in weze niets uit. Want dan is het aantal reads ongeveer hetzelfde.

Wanneer die file opsplitst in 3 files (< 1 KB), dan zou het wel uit kunnen maken want wat je anders in 1 read kan doen, moet je nu 3 reads doen. Maar nogmaals, deze "overhead" is te verwaarlozen ten opzichte van de andere taken die PHP doet.

putStr $ map (x -> chr $ round $ 21/2 * x^3 - 92 * x^2 + 503/2 * x - 105) [1..4]


  • surfdude
  • Registratie: Maart 2000
  • Laatst online: 16-06 22:34
OK, thnx

topic closed ;)

of toch niet? :P

Het kan altijd mooier en beter...

Pagina: 1