---

Jeg har lavet noget kode hvor der bliver oprettet et objekt af ca. 7 forsk.
klasser i gennemsnit for hver side eksekvering. Problemet er at det tager
0,5 til 1 sekund for PHP at eksekvere siden.

Jeg prøvede at udkommentere oprettelsen af et objekt af en klasse. Det alene
betød en reduktion i eksekveringstiden på 0,1 sekund!

Er det meget normalt at det skal gå så langsomt, eller er det mig der
programmerer for "store" scripts?

Generelt kalder mange af klasserne hinanden, lidt "på kryds og tværs", når
det er nødvendigt. Det ser jeg som den rigtige måde i OOP tankegang. Men det
kunne tyde på at det giver performance straf at programmere for meget objekt
orienteret i PHP?

Jeg bruger ADODB og mange af klasserne kalder sit eget ADODB objekt. Koster
det meget performance?

Disse tider er på en en XP1800+. Jeg prøvede på et tidspunkt at uploade et
"tælle script" der bare kører en lykke. Det tog under et sekund hos mig og
op til 11 sekunder på et webhotel jeg testede på.

---

Tinky Winky wrote:
> Jeg har lavet noget kode hvor der bliver oprettet et objekt af ca. 7 forsk.
> klasser i gennemsnit for hver side eksekvering. Problemet er at det tager
> 0,5 til 1 sekund for PHP at eksekvere siden.

Det lyder voldsomt

> Generelt kalder mange af klasserne hinanden, lidt "på kryds og tværs", når
> det er nødvendigt. Det ser jeg som den rigtige måde i OOP tankegang. Men det
> kunne tyde på at det giver performance straf at programmere for meget objekt
> orienteret i PHP?

Njah - jeg tror at hammeren falder hvis man ikke samtidig med at man
tænker OO tænker en hel del i struktur.
Nu har jeg jo ikke set din kode, så det jeg skriver er rimeligvis ikke
en udtalelse om hvordan den ser ud

> Jeg bruger ADODB og mange af klasserne kalder sit eget ADODB objekt. Koster
> det meget performance?

Mange db-kald er altid dyrt i afviklingstid. Hvis du kan minimere
antallet af kald ved at medsende data-objekter i dine klasse-kald vil
det sikkert optimere en del.

Antallet af små klasser med separat funktionalitet er derudover altid en
afvejning imellem at skille unik (genbrugelig) funktionalitet ud for sig
selv; at lave større klasser hvor kodestumper som findes andre steder
gentages.

Endelig er det min erfaring at jeg af og til skal passe på at jeg ikke
for mange gange tilpasser en funktion eller klasse til at klare en
opgave i endnu en sammenhæng, hvorved jeg lægger millisekunder på de 6
(eller 16) klasser som bruger den i forvejen...

mvh

Jesper Brunholm



--
H.C. Andersen-Centret med nyt design: <http://www.andersen.sdu.dk/>
Phønix - dansk folk-musik fra unge musikere - <http://www.phonixfolk.dk/>

---

> > Jeg bruger ADODB og mange af klasserne kalder sit eget ADODB objekt.
Koster
> > det meget performance?
>
> Mange db-kald er altid dyrt i afviklingstid. Hvis du kan minimere
> antallet af kald ved at medsende data-objekter i dine klasse-kald vil
> det sikkert optimere en del.

Ved at kommentere lidt ud, kan jeg også se at det er den klasse der tager
tid. Men lad os sige, at jeg kun havde et ADODB objekt, som blev sendt
videre som parameter, ville det ikke kunne give problemer at flere objekter
arbejder på det samme ADODB objekt?

Blot at oprette et objekt tager vel ikke så lang tid medmindre dette objekt
ved oprettelsen (i constructoren) laver et DB kald. Jeg tror ADODB laver et
DB kald blot man laver et objekt af klassen.

I øjeblikket laver alle klasser der bruger databasen, et objekt af en
bestemt klasse, hvori der er en funktion der returnerer et ADODB connection
objekt. Det skal laves om. Har du et forslag?

> Antallet af små klasser med separat funktionalitet er derudover altid en
> afvejning imellem at skille unik (genbrugelig) funktionalitet ud for sig
> selv; at lave større klasser hvor kodestumper som findes andre steder
> gentages.

Kan du sige noget om hvor lang tid det tager at have fx 400 linjers, i nogle
sammenhænge, overflødig kode i en klasse vs. at loade 3 forsk. 100 linjers
klasser?

---

Tinky Winky wrote:

> Kan du sige noget om hvor lang tid det tager at have fx 400 linjers,
> i nogle sammenhænge, overflødig kode i en klasse vs. at loade 3
> forsk. 100 linjers klasser?

Jeg husker at det var oppe at vende, da Lerdorf var her for et par år siden
og holde fordrag, at man med fordel kunne springe ud og ind af php f.eks.
når man hælder en masse <TR> <TD> ud + det var en fin ide at benytte unset()
til variabler, der ikke længere blev brugt, da unset() skulle fungere ala en
destructor i C++

--
Take Care
Kim Emax - Freelance programmør
http://www.emax.dk - http://www.ayianapa.dk
Køb din vin online på http://www.gmvin.dk,
Danmarks måske mest avancerede VinWebShop

---

> > Kan du sige noget om hvor lang tid det tager at have fx 400 linjers,
> > i nogle sammenhænge, overflødig kode i en klasse vs. at loade 3
> > forsk. 100 linjers klasser?
>
> Jeg husker at det var oppe at vende, da Lerdorf var her for et par år
siden
> og holde fordrag, at man med fordel kunne springe ud og ind af php f.eks.
> når man hælder en masse <TR> <TD> ud + det var en fin ide at benytte
unset()
> til variabler, der ikke længere blev brugt, da unset() skulle fungere ala
en
> destructor i C++

Jeg bruger ikke HTML inde i PHP filerne, de er i templates. Men unset() kan
jeg måske bruge.

---

Tinky Winky wrote:

> >>Jeg bruger ADODB og mange af klasserne kalder sit eget ADODB objekt.
>
> Koster
>
> >>det meget performance?
> >
> >Mange db-kald er altid dyrt i afviklingstid. Hvis du kan minimere
> >antallet af kald ved at medsende data-objekter i dine klasse-kald vil
> >det sikkert optimere en del.
>
>
> Ved at kommentere lidt ud, kan jeg også se at det er den klasse der tager
> tid. Men lad os sige, at jeg kun havde et ADODB objekt, som blev sendt
> videre som parameter, ville det ikke kunne give problemer at flere
> objekter
> arbejder på det samme ADODB objekt?


det kommer vel an på om objektet formatteres i den rækkefølge som det
skal bruges, jeg har lidt svært ved at sætte mig ind i hvad det er du gør

> Blot at oprette et objekt tager vel ikke så lang tid medmindre dette
> objekt
> ved oprettelsen (i constructoren) laver et DB kald.


enig

> Jeg tror ADODB laver et
> DB kald blot man laver et objekt af klassen.


hvis du så også laver flere objekter, så ender det jo med at være en del
data at jonglere rundt med

> I øjeblikket laver alle klasser der bruger databasen, et objekt af en
> bestemt klasse, hvori der er en funktion der returnerer et ADODB
> connection
> objekt. Det skal laves om. Har du et forslag?

Oprigtigt talt så kender jeg ikke ADODB ret godt, så jeg kan ikke sige
noget om hvordan præcis den db udnyttes godt.

Konkret så kommer det jo utroligt meget an på hvad det er for data der
skal behandles - færre objekter i spil, og færre kald til db skulle
gerne give bedre afviklingstid...

Prøv at tænke en side-gennemkørsel igennem: hvor mange forskellige
objekter ændres der i databasen (hvis nu du skulle rette det manuelt,
men som maskinen kan sende til rækker i flere tabeller på en gang, hvor
mange skulle du så skrive ind?). Sammenlign det antal med antallet af
database-kald på den fuld side-gennemkørsel.

> >Antallet af små klasser med separat funktionalitet er derudover altid en
> >afvejning imellem at skille unik (genbrugelig) funktionalitet ud for sig
> >selv; at lave større klasser hvor kodestumper som findes andre steder
> >gentages.


> Kan du sige noget om hvor lang tid det tager at have fx 400 linjers, i
> nogle
> sammenhænge, overflødig kode i en klasse vs. at loade 3 forsk. 100 linjers
> klasser?


nej - men det gør nok en forskel om afgørelsen om overflødighed træffes
med 20 if-sætninger og sågar et par reg-x-sammenligninger eller med
noget enklere

mvh

Jesper Brunholm

---

Tinky Winky wrote:
>> Mange db-kald er altid dyrt i afviklingstid. Hvis du kan minimere
>> antallet af kald ved at medsende data-objekter i dine klasse-kald vil
>> det sikkert optimere en del.
>
> Ved at kommentere lidt ud, kan jeg også se at det er den klasse der tager
> tid. Men lad os sige, at jeg kun havde et ADODB objekt, som blev sendt
> videre som parameter, ville det ikke kunne give problemer at flere
> objekter arbejder på det samme ADODB objekt?

Med ADO får man vel også et recordset ud som resultat, som man så bruger til
at hente rækker fra osv(har aldrig brugt det - det lugter af windows ;))?

> Blot at oprette et objekt tager vel ikke så lang tid medmindre dette
> objekt ved oprettelsen (i constructoren) laver et DB kald. Jeg tror ADODB
> laver et DB kald blot man laver et objekt af klassen.

Hvis det gør det, er det godt nok grimt :/

> I øjeblikket laver alle klasser der bruger databasen, et objekt af en
> bestemt klasse, hvori der er en funktion der returnerer et ADODB
> connection objekt. Det skal laves om. Har du et forslag?

PEAR. - brug den static-emulering der er lavet i PEAR (når der så
engang(php5) kommer rigtige statiske variable på klasser
($DinKlasse::connection) kan du bruge dem i stedet) - så har du kun en
instans af din ADO klasse og slipper samtidigt for at skulle sende den med
som parameter på alle metoder.

--
Regards,
Nezar Nielsen

Worldfamous sheepherder.

---

> > Blot at oprette et objekt tager vel ikke så lang tid medmindre dette
> > objekt ved oprettelsen (i constructoren) laver et DB kald. Jeg tror
ADODB
> > laver et DB kald blot man laver et objekt af klassen.
>
> Hvis det gør det, er det godt nok grimt :/

Det gør den ikke, men det gjorde den sådan som jeg havde implementeret den
før
Nu opretter jeg i stedet et enkelt adodb objekt og connecter til DB, i
starten af hver eksekvering og sender referencer til det objekt rundt som
parametre fx
"function foo(& $databaseobjekt)". Jeg har også prøvet at skrive "global
$dbobject;" og derefter "$lokaltdbreference = & $dbobject;" og det virkede
også fint. Men jeg holder mig nok til parametrene.

Nu ligger eksekveringstiden i mellem 0,1 og 0,2 sekunder. Et bedre
udgangspunkt. Så kan jeg optimere herfra.

> > I øjeblikket laver alle klasser der bruger databasen, et objekt af en
> > bestemt klasse, hvori der er en funktion der returnerer et ADODB
> > connection objekt. Det skal laves om. Har du et forslag?
>
> PEAR. - brug den static-emulering der er lavet i PEAR (når der så
> engang(php5) kommer rigtige statiske variable på klasser
> ($DinKlasse::connection) kan du bruge dem i stedet) - så har du kun en
> instans af din ADO klasse og slipper samtidigt for at skulle sende den med
> som parameter på alle metoder.

Jeg er ikke helt tilfreds med at PEAR er et ekstra modul, som skal være
installeret på webserveren. ADODB funger godt nok og gør det mere portabelt.
Men ellers tak for forslaget.

---

Tinky Winky wrote:

> Jeg er ikke helt tilfreds med at PEAR er et ekstra modul, som skal være
> installeret på webserveren. ADODB funger godt nok og gør det mere
> portabelt. Men ellers tak for forslaget.

PEAR er skam ikke noget ekstra modul der skal compiles ind, det er pure
php-kode som du jo sagtens ville kunne distribuere med din kode hvis det
var (om licensen tillader det aner jeg ikke).

At der så findes PEAR (eller PECL) extensions der skal compiles ind, er en
anden ting, men pr. default er PEAR bare PEAR.php (og børn).


--
Regards,
Nezar Nielsen

Worldfamous sheepherder.

---

Nezar Nielsen wrote:
>
> PEAR er skam ikke noget ekstra modul der skal compiles ind, det er pure
> php-kode som du jo sagtens ville kunne distribuere med din kode hvis det
> var (om licensen tillader det aner jeg ikke).

Det gør den.

--
Jonas Koch Bentzen