require("diverseFunktioner.php")

En funktion bliver ikke eksekveret, før der kaldes på den.

Ja, du spilder tiden lidt, ved at den skal parse en række unødvendige funktioner. Hvorfor tror du det betyder noget?

Hvis du bekymrer dig om ressourcer, så har du valgt et forkert sprog til at starte om. ;-)

Den smule ressourcer du spilder på det der tvivler jeg på overhovedet kan påvirke millisekunderne.

Tak skal I ha' - min mistanke er bekræftet : (
- havde håbet at i ville sige at den blot "registrerede tilstedeværelsen" af funktionerne, men ikke begyndte at parse deres kroppe før nødvendigt..

Problemet er at jeg også inkluderer hele baduljen i en AJAX(lignende) konstruktion jeg bruger
- hvor selve det arbejde der reelt skal udføres kun er .. måske 10 linjer.
I de tilfælde er det jo (så) klart forsinkende.

Bare "rart" at have dem samlet, i stedet for i 20 separate filer...
- Nå, jeg smider dem i en 'tools-mappe' i stedet - så er de stadig nogenlunde samlet, selvom det giver en del mere spindelvæv, i de tilfælde hvor de "bruger hinanden".

Måske:
både samlet i én fil, til når jeg skal bruge mange af dem (hurtigere indlæsning) ?
og i separate filer, til når jeg kun skal bruge en eller to.

Nogen kommentarer til dén strategi ?

At have tre forskellige steder at vedligholde den nøjagtige samme kode virker en smule omsonst for mit vedkommende (og stik imod formålet med ens egne forventninger til udvikling).

Nu ved jeg ikke hvor meget mere end de 350 liniers kode du indlæser hver gang du har en visning; men jeg er faktisk helt overbevist om at hvis du helt undlod at inkludere din funktionsfil, så ville du slet ikke kunne mærke en performanceforskel der er værd at bemærke.

Til sammenligning kan jeg da nævne PEAR bibliotekerne - mage til overflødighedshorn af kode, for at benytte deres MIME mail klasse støder man hvis kun på i PEAR's andre lignende biblioteker; man alligevel er der vældigt mange udviklere og webapplikationer der sværger til PEAR's effektivitet - personligt ville jeg aldrig røre det med en ildtang.

For at gøre det mindre abstrakt, så forestil dig mængden af kode som du indlæser når du bruger et større framework (som CodeIgniter, CakePHP, Yii og så videre) men som stadig yder performancemæssigt godt?

De andre har allerede sagt det, men dit fokus ligger forkert - PHP er et klytsprog på trods af dets effektivitet til at lave dynamiske hjemmesider og webapplikationer. Men performance problemer ligger sjældent i inkludering af funktioner og klasser.

Det var dejligt at høre : )
Og nu du nævner det, så bruger jeg faktisk HTML-purifier = MANGE php-filer.
- men den leverer også, stort set, øjeblikkeligt.

Jeg bekymrer mig nok for meget om performance, og for lidt om at BLIVE FÆRDIG med lortet : )

Godt så - jeg lader det være (indtil jeg FAKTISK konstaterer performanceproblemer)

Points til dig og wanze - hvis i lægger et svar hver.

PS: webweaver: Tak også, men dén var for let : )

Jamen, jeg lægger et svar da :)

Jeg er enig med de øvrige i, at du ikke behøver bekymre dig om performance af det. Men jeg ville klart foretrække, ikke at gemme det hele i én fil, ikke pga. performance, men pga. vedligeholdelse.

Hvis man arbejder med en 10-20 funktioner, kan det gå, men hvis filen efterhånden kommer op på 60-70 funktioner, der kan alt fra hente HTML/JSON til gemme data i diverse tabeller, vil det blive besværligt at vedligeholde. Når du om et halvt år skal tilbage og lave et par ændringer.

Det ville klart være at foretrække, at koden var delt i passende mindre filer, der hver havde én ansvarsområde. Det er dog ikke så nemt når man kun arbejder med funktioner. Objekt orienteret programmering kan hjælpe med at løse dette på en effektiv måde.

Men jeg er også enig i, at du ikke bør lave det om. Det handler også om, ikke at skulle starte forfra hver gang man får en ny optimeringsidé. "Premature optimization is the root of all evil".

Premature optimization is the root of all evil : D
Jeg skriver det med jule-guld på rammen over min skærm






Åh nej, bare jeg ikke dér kom til, at kick-starte årets julepsykose..

Julelunten.