Kan det betale sig at have denne kode:
<?php include("file includes/eksempel.php"); ?>
Hvor eksempel.php ser s�dan her ud:
kage-kage-kage
<?php include("file includes/pandekage.php"); ?>
Alts�: Kan jeg have en include file, inden i en file der allerede
er included et sted?
Vil det f� min side at loade langsommere?
-Mads
--
Vil du l�re at kode HTML, XHTML, CSS, SSI, ASP eller ASP.NET?
- P�dagogiske tutorials p� dansk
- Kom godt i gang med koderne
KLIK HER! => http://www.html.dk/tutorials
> Kan det betale sig at have denne kode:
> <?php include("file includes/eksempel.php"); ?>
Lav koden s� den er overskuelig og nem at vedligeholde. S�t
spekulationer over hastighed langt ned p� din prioritetsliste.
Indlejrede includes kan godt give mening hvis man har flere
undermoduler der f.eks. deler en stribe funktioner..
Brug include_once(). S� kan du kalde et modul flere gange uden at
der inkluderes mere end n�dvendigt.
> Vil det f� min side at loade langsommere?
Fisk.
--
Bertel
http://bertel.lundhansen.dk/ FIDUSO: http://fiduso.dk/
Hvad mener du med, om det kan betale sig?
Hvis din index f.eks. includerer en fil der behandler menuer og
menuvalg, kan du i den sagtens have en include, der henter data for det
aktuelle menuvalg.
Sᅵ Ja - du kan godt. Men om det er overskueligt og besparende er nok et
andet spᅵrgsmᅵl.
Det har nok virkning pᅵ hastigheden - men man skal nok mᅵle den i
millisekunder, sᅵ det er ikke noget man behᅵver prioritere sᅵrlig hᅵjt.
Birger
--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk
> Alts�: Kan jeg have en include file, inden i en file der allerede
> er included et sted?
> Vil det f� min side at loade langsommere?
Fyr den af og g�r, hvad der passer dig bedst. S� l�nge du kan finde en
evt. fejl er der ingen problemer.
Hvis hastigheden bliver et problem, b�r du kigge p� caching af
resultatet af dine scripts.
Desuden mener jeg, du b�r bruge require_once() i stedet for include().
require() og require_once() smider en fatal error, hvis filen ikke
findes (s� afviklingen stopper helt), hvilket ikke er tilf�ldet med
include() og include_once() - de smider bare en fejl, men afvikler s�
resten af dit script. Hvis en fil mangler, kan det n�ppe v�re meningen
at scriptet skal forts�tte med at afvikles.
- Peter
Man skal dog v�re opm�rksom p� der kan v�re et issue omkring
performance, n�r man leger med include_once og require_once - det er
ikke det bedste rent performancem�ssigt, hvis vi taler om store systemer
med mange inkluderede filer (hvilket jeg dog ikke tror er tilf�ldet i
denne sag!). S� det er skidt at vende sig til at bruge den, hvis der
ikke er en �rsag (hvilket der sj�ldnet b�r v�re!).
I systemer hvor der inkluderes rigtig mange filer kan der komme en
*betydelig* performanceoptimering, blot ved at rette alle require_once
(eller include_once) til require (eller include).
Mvh
Johan
<?php include("file includes/body_start.php"); ?>
<?php include("file includes/menu.php"); ?>
<?php include("file includes/artikel_start.php"); ?><?php include("file
includes/forside.php"); ?>
<?php include("file includes/artikel_end.php"); ?>
<?php include("file includes/sidefod.php"); ?>
<?php include("file includes/body_end.php"); ?>
Da det siger mig mest.
Jeg ved godt at jeg ikke beh�vede at include forside.php (kunne bare ha'
skrevet den direkte) men det her foretr�kker jeg da jeg ikke f�r pillet
ved noget s� der opst�r fejl :)
Siden er p� horndrup.eu/lalala.php hvis i vil se virkningen (;
Det er rigtigt. Nu har jeg desv�rre ikke lige et link til kilden, men
har l�st en blog post om der n�rmest intet overhead er, hvis man bruger
f.eks. APC. Det virker ret sandsynligt at man vil g�re det, hvis man
inkluderer mange filer.
- Peter
Om det kan betale sig afhænger jo af hvad du prøver på at gøre. Det er
lidt svært at sige ud fra dit eksempel. Hvis det giver en logisk
inddeling og strukturering i din kode, så vil jeg mene at det sagtens
kan betale sig.
> Alts : Kan jeg have en include file, inden i en file der allerede
> er included et sted?
Man kan sagtens have includes inde i "includede" filer. Det PHP gør er
ikke andet end at tage koden i filen og "indsætte" den i den anden fil
før den bliver eksekveret. Fra PHPs synspunkt er der altså ingen
forskel på om din kode ligger i en fil du includer eller om den står
direkte i din anden fil (så længe filen altså findes).
> Vil det få min side at loade langsommere?
Disk I/O er generelt langsomt, så jo flere gange du skal have fat i
ting på din harddisk i runtime, jo langsommere bliver dit program. Så
ja, jo flere includes, jo langsommere bliver det. Det er dog
formentlig ikke noget der vil have særligt stor betydning for dig med
mindre du har en side med rigtigt meget traffik. Et kald til
include_once vil også være langsommere end include (tilsvarende for
require_once or require) da den skal hold en liste over alle includede
filer og tjekke den først.
En opcode cache som APC hjælpe mod begge ting. Når PHP har parset et
stykke kode får den nogle opcodes som er instruktioner til PHPs kerne
(Zend Engine/ZE). Det en opcode cache gør at den gemmer resultatet
dette i hukommelsen, som er meget hurtigere at læse fra og skrive til
end harddisken. Det betyder at hvis du ikke har ændret i din fil, så
behøver filen ikke at blive indlæst og parset igen; den kan bare
hentes direkte fra hukommelsen. APC giver dig også mulighed for helt
at springe harddisken over (så den slet ikke undersøger om filerne er
blevet ændret). Det betyder dog at du skal genstarte din webserver (og
miste din cache!) hver gang du ændrer dine filer.
Generelt er det altid anbefalet et køre APC (eller tilsvarende) i et
produktionsmiljø og det kan give performance forbedringer på op til
flere størrelsesordener.
Bottom line: Du behøver generelt ikke at bekymre dig om at have for
mange includes eller requires. Du vinder meget mere ved at have
overskuelig og velstruktureret kode end hvad du måtte miste i
performance, og hvis du endelig har nok traffik til at det har
betydning så vil APC ordne det meste.
http://dk2.php.net/manual/en/function.include.php :
"When a file is included, parsing drops out of PHP mode and into HTML
mode at the beginning of the target file, and resumes again at the end.
.."
Det er "resultatet" af den includede fil der indsᅵttes - ikke filen
selv.
Ellers ganske enig.
Birger.
Ja, jeg kunne måske godt have forklaret det bedre. Det er klart at den
selvfølgelig ikke bare copy-paster koden ind i den anden fil. Det der
sker når PHP møder et include/require(_once) er at compile_filename()
i ZE bliver kaldt. Den includede fil vil så overtage både EG
(symbol_table) og EG(active_symbol_table), der er hashtabeller som
indeholder symbolnavne i hhv. det globale og lokale virkefelt (så man
kan sige at den bare arbejder videre). Når PHP starter med at parse en
fil starter den altid uden for "PHP mode" så den smider bare alt hvad
den møder indtil den kommer til "<?php" til STDOUT, og det er sådan
set bare det dit citat fra manualen mener. Når den er færdig med den
includede fil fortsætter den fra hvor den slap.
Så ja, det er sådan set "resultatet" du får igen, men jeg synes det
giver fint mening rent kognitivt at hvis man har følgende to filer:
fil1.php:
<?php
$foo = 'bar';
include 'fil2.php';
?>
fil2.php:
<?php
echo $foo;
?>
Så har du *reelt* følgende:
<?php
$foo = 'bar';
echo $foo;
?>
Eller for at være helt nøjagtig når nu den starter uden for "PHP
mode":
<?php
$foo = 'bar';
?><?php
echo $foo;
?><?php ?>
Den vigtige pointe er selvfølgelig at du i løbet af dette vil få en
række opcodes i den inkluderede fil og hvis du kører APC så kan den
cache disse. Dvs. at næste gang du inkluderer den, så kan den bare
hente disse opcodes og bruge dem direkte.
Mht. opcode caching kan jeg nævne at jeg driver en "mellemstor" side
og her bliver opcode cachen ramt ca. 52 gange hvert sekund. Det er
altså 52 gange i sekundet at PHP slipper for at parse en masse filer
om og om igen. Står man med en side om Facebook bliver gevinsten
naturligt meget større.
--
Daniel Egeberg
dege...@php.net
Hvorfor alle de PHP blokke? F�lgende vil v�re langt mere l�seligt:
<?php
include("file includes/head.php");
include("file includes/body_start.php");
include("file includes/menu.php");
include("file includes/artikel_start.php");
include("file includes/forside.php");
include("file includes/artikel_end.php");
include("file includes/sidefod.php");
include("file includes/body_end.php");
?>
I �vrigt er det ikke en god id� med mellemrum i fil og mappenavne. Det
risikere bare at give en masse b�vl.
- Chano Andersen
> Hvorfor alle de PHP blokke? F�lgende vil v�re langt mere l�seligt:
Ligger Dennis Munding i dit killfilter?
Mads Horndrup skrev...
> Tak for alle svarene.
> Det endte med at jeg gjorde s�dan her:
> <?php include("file includes/head.php"); ?>
>
> <?php include("file includes/body_start.php"); ?>
> <?php include("file includes/menu.php"); ?>
> <?php include("file includes/artikel_start.php"); ?><?php include("file
> includes/forside.php"); ?>
> <?php include("file includes/artikel_end.php"); ?>
> <?php include("file includes/sidefod.php"); ?>
> <?php include("file includes/body_end.php"); ?>
Hvis du helt bogstaveligt har en fil, der ser ud som ovenst�ende, s� kan jeg
spare dig for lidt kode...:
<?php
include("file includes/head.php");
include("file includes/body_start.php");
include("file includes/menu.php");
include("file includes/artikel_start.php");
include("file includes/forside.php");
include("file includes/artikel_end.php");
include("file includes/sidefod.php");
include("file includes/body_end.php");
?>
Det vil give samme resultat.
Er ikke s� meget inde i php, at jeg ved, om det kan komprimeres yderligere,
men det er der sikkert en anden, der ved... :-)
Med venlig hilsen
--
Dennis Munding
a.k.a. The Eye - Member of the PosseGrim Squad
http://pgsquad.com/
"When you hear the wind - you're already dead..."
> Ligger Dennis Munding i dit killfilter?
OK! Stofanet-indl�ggene igen.
B�de dit og Dennis Mundings indl�g er ogs� f�rst dukket op hos mig nu.
--
Philip - http://www.chartbase.dk | http://www.hitsurf.dk
> > Ligger Dennis Munding i dit killfilter?
> OK! Stofanet-indl�ggene igen.
�h ja, selvf�lgelig.
> Hvis du helt bogstaveligt har en fil, der ser ud som ovenst�ende, s�
> kan jeg spare dig for lidt kode...:
>
> <?php
> include("file includes/head.php");
> include("file includes/body_start.php");
> include("file includes/menu.php");
> include("file includes/artikel_start.php");
> include("file includes/forside.php");
> include("file includes/artikel_end.php");
> include("file includes/sidefod.php");
> include("file includes/body_end.php");
> ?>
> Det vil give samme resultat.
> Er ikke s� meget inde i php, at jeg ved, om det kan komprimeres
> yderligere, men det er der sikkert en anden, der ved... :-)
Det er vist s� meget, som det kan komprimeres. Men du har ret, der er ikke
nogen grund til at lukke php ned efter hver enkelt include og s� gen�bne php
for n�ste include.
--
Med venlig hilsen
Erik Ginnerskov
http://ginnerskov.dk - http://html-faq.dk
Brug dog news.dotsrc.org, s� er I ude over det problem. Det er jo ikke
f�rste gang, Stofa har problemer med opdateringen.
> Brug dog news.dotsrc.org, s� er I ude over det problem. Det er jo ikke
> f�rste gang, Stofa har problemer med opdateringen.
news.stofanet.dk har haft f�rre problemer end news.dotsrcorg.sk.
Jeg regner dem dog begge for suver�ne newsservere.
Jeg t�nker som s� at n�r jeg har adgang til en god newserver via
mit abonnement, s� er der ingen grund til at belaste en gratis
tjeneste.
Eneste mulighed for at pakke det mere sammen ville v�re at fjerne
linjeskift, eller se om man kan inkludere nogle af tingene i en af de
andre filer.
- Chano Andersen
For at v�re �rlig, s� ved jeg faktisk ikke hvor den funktion findes i
Thunderbird. S� det er nok n�rmere det andetsteds omtalte stofanet problem.
- Chano Andersen