---

Hej !

Jeg koder noget perl til websites, det interfacer med en MySQL database, men
hvad er egenligt hurtigst ?
perl eller php ?

mvh.Simon

---

On Sun, 28 Sep 2003 11:47:12 GMT
"Simon [2700]" <devnull@linux.org> wrote:

> Hej !
>
> Jeg koder noget perl til websites, det interfacer med en MySQL database, men
> hvad er egenligt hurtigst ?
> perl eller php ?

jeg synes at udvikling med mod databaser er lang hurtigere og pænere i php, men performance mæssigt tror jeg ikke der er nogen mærkbar forskel. umiddelbart synes jeg at perl bruger lidt mere hukommelse til det end php, men det er ikke noget jeg kan dokumentere på nogen måde.

---

Hmmm, php
"Kim Schulz" <kim@schulz.dk> skrev i en meddelelse
news:20030928142325.6b537fa4.kim@schulz.dk...
On Sun, 28 Sep 2003 11:47:12 GMT
"Simon [2700]" <devnull@linux.org> wrote:

> Hej !
>
> Jeg koder noget perl til websites, det interfacer med en MySQL database,
men
> hvad er egenligt hurtigst ?
> perl eller php ?

jeg synes at udvikling med mod databaser er lang hurtigere og pænere i php,
men performance mæssigt tror jeg ikke der er nogen mærkbar forskel.
umiddelbart synes jeg at perl bruger lidt mere hukommelse til det end php,
men det er ikke noget jeg kan dokumentere på nogen måde.

---

On Sun, 28 Sep 2003 11:47:12 GMT, Simon wrote:

> Jeg koder noget perl til websites, det interfacer med en MySQL
> database, men hvad er egenligt hurtigst ? perl eller php ?

Til hvad?

Hvilke faktorer indregner du i "hurtigst" - udviklingstid,
afviklingstid, udtryksfuldhed, miljø, tilgang til kvalificerede
programmører, typer af opgaver, portabilitet, benchmarks,
osv. osv....?


Mvh.

--
"Vi är små citroner" Adam Sjøgren
asjo@koldfront.dk

---

> Hvilke faktorer indregner du i "hurtigst" - udviklingstid,
> afviklingstid, udtryksfuldhed, miljø, tilgang til kvalificerede
> programmører, typer af opgaver, portabilitet, benchmarks,
> osv. osv....?

benchmarks / afviklingstid, ved brug af database operationer.
mvh.simon

---

Simon [2700] wrote:
> afviklingstid, ved brug af database operationer.

Så skal du bruge C.

Tilgengæld skal du så til at kæmpe med lange udviklingstider, mangel på
sikkerhed og inflexibilitet.


Når du rode med databaser er det stort set altid databasen der bruger al
cputiden, så det betyder ingen ting hvor hurtigt dit applikationssprog er.

Personligt vil jeg anbefale Perl, fordi:
* Der er mange rigtigt pæne moduler på CPAN <http://cpan.dk> som kan
stort set alt du har lyst til at kunne.

* Performance er rigtigt god, hvis du bruger det rigtigt, Perl er IKKE
C.

* Perls syntax er meget høj-niveau og "stor", det gør at det er let
at udtrykke dine ønsker og at det er let at forstå og vedligeholde,
hvis du bruger det rigtigt, ellers er det lige så let at sætte write
only bitten.

* Du kan skrive andre applikationer i Perl end webapplikationer så du
kan genbruge en masse kode og Perl er ikke bundet til en webserver.

* Der er mange kompetente menesker der kan Perl, som gerne vil give dig
en hånd og der er meget materiale på Nettet om Perl, det betyder at du
kommer til at lede længe efter en opgave du ikke kan løse i Perl.


Jeg vil advare mod PHP, fordi:
* PHP er ufatteligt grimt og dårligt designet. (mange underlige
specialcases og hovsa-løsninger rundt omkring)

* Hvis du skal udvide php skal du til at hakke i C sourcen som er
monolitisk.


Perl kan have det med at fylde meget mere end php, alene fordi perl er
et meget større sprog der kan meget mere, men den største grund til at
perl bruger meget RAM er at koden bliver kompileret og gemt i
hukommelsen, samtidigt er det let at skrive perl moduler i Perl, det gør
at de importerede moduler også kommer til at spise RAM.

--
Regards Flemming Frandsen - http://dion.swamp.dk
PartyTicket.Net co founder & Yet Another Perl Hacker

---

On Sun, 28 Sep 2003 19:06:22 +0200,
Flemming Frandsen <ff-news.tiscali.dk@partyticket.net> wrote:

> Når du rode med databaser er det stort set altid databasen der bruger al
> cputiden, så det betyder ingen ting hvor hurtigt dit applikationssprog er.

Yup, databaser er cpu-bundne.

> * Der er mange rigtigt pæne moduler på CPAN <http://cpan.dk> som kan
> stort set alt du har lyst til at kunne.

Det ser jeg ikke som en fordel. Med maengden af crap der er i CPAN og
hvor lidt forskellige pakker virker sammen er det en joke. Derudover
kommer problemet med at du for at anvende program X lige skal have
20 CPAN moduler.

> Jeg vil advare mod PHP, fordi:
> * PHP er ufatteligt grimt og dårligt designet. (mange underlige
> specialcases og hovsa-løsninger rundt omkring)

Enig. Det er ikke semantisk veldefineret og mange er tingene er
noget forbandet skidt.

> * Hvis du skal udvide php skal du til at hakke i C sourcen som er
> monolitisk.

Men det her er en fordel. Du har pludselig en veldefineret graenseflade
og undgaar selvsamme modulhelvede fra perl. Jeg vil tro at det er en
af hovedaarsagerne til at PHP klarer sig.

--
Jesper

---

Jesper Louis Andersen wrote:
>>* Der er mange rigtigt pæne moduler på CPAN <http://cpan.dk> som kan
>> stort set alt du har lyst til at kunne.
>
> Det ser jeg ikke som en fordel. Med maengden af crap der er i CPAN og
> hvor lidt forskellige pakker virker sammen er det en joke.

Øh, er du fuld?

Ja, der er en del crap moduler med sindsyge dependencies, men der er
også mange rigtigt velskrevne moduler som gør ret komplekse ting meget
simpelt.

Selv de dårlige moduler er nyttige, for hvis du får hentet et skodmodul
som gør tingene forkert vil du typisk kunne genbruge nogle stumper i din
egen fejlfri version af det samme.


> Derudover kommer problemet med at du for at anvende program X lige
> skal have 20 CPAN moduler.

Det er ikke et problem, installer cpan shell, så finder den selv
dependancies for dig:

cpan
> install Modul::Helvede
.... finder, downloader, compilerer, tester og installerer
Module::helvede samt de 20 moduler det afhænger af.

På windows hedder det vist ppm og er lavet af ActiveState, men det gør
det samme.


> Jeg vil tro at det er en af hovedaarsagerne til at PHP klarer sig.

Det tror jeg måske du har ret i, det er meget let at lave en apache med
PHP indbygget, som folk kan bruge out of the box fordi der kun er en
måde at skrive php-kode-i-hver-side baserede applikationer på.

Med Perl er der mindst 10 forskellige måde at skrive webapplikationer
på, personligt mener jeg at det er noget rod at putte al koden i
templaten og mappe templaten direkte til url'en, men derfor er jeg også
glad for at jeg ikke er låst til netop en løsning med Perl.

--
Regards Flemming Frandsen - http://dion.swamp.dk
PartyTicket.Net co founder & Yet Another Perl Hacker

---

Flemming Frandsen wrote:
>
> Ja, der er en del crap moduler med sindsyge dependencies, men der er
> også mange rigtigt velskrevne moduler som gør ret komplekse ting meget
> simpelt.

enig.

>
> Det er ikke et problem, installer cpan shell, så finder den selv
> dependancies for dig:
>
> cpan
> > install Modul::Helvede
> ... finder, downloader, compilerer, tester og installerer
> Module::helvede samt de 20 moduler det afhænger af.
>

mjaeh, i en perfekt verden, men hvis vi er ovre i XS moduler så er der
jo tit dependencies til C-biblioteker som man måske ikke nødvendigvis
har på sin maskine og som cpan ikke kan finde ud af at installere

Det kan godt være at kodebasen endnu ikke er så stor, men med php kan
man jo også bruge PEAR, som er php's pendent til CPAN...

eg:

[root@linux root]# pear install MDB
som også henter og compiler hvis det er nødvendigt...

> Med Perl er der mindst 10 forskellige måde at skrive webapplikationer
> på, personligt mener jeg at det er noget rod at putte al koden i
> templaten og mappe templaten direkte til url'en, men derfor er jeg også
> glad for at jeg ikke er låst til netop en løsning med Perl.

Det er man da heller ikke med php, fx. Smarty templates...

--
Mvh. Nezar Nielsen
http://fez.dk

---

On the CCLXXII'nd day of the MMIII'rd year, Nezar Nielsen spoketh:

> mjaeh, i en perfekt verden, men hvis vi er ovre i XS moduler så er
> der jo tit dependencies til C-biblioteker som man måske ikke
> nødvendigvis har på sin maskine og som cpan ikke kan finde ud af
> at installere

Bruker man windows, er det lurt å bruke ppm fra Activestate istedet
for cpan. Det gir mindre problemer med XS-moduler.
--
(,_ ,_, _,)
/|\`\._( )_./'/|\
· · \/ L /\ D · ·
/__|.-'`-\_/-`'-.|__\
`·..·´¯`·..·´¯`·..·´¯`·..·´¯`·..·´¯`·..·´¯`·.. ` " `

---

Flemming Frandsen wrote:

> Det tror jeg måske du har ret i, det er meget let at lave en apache
> med PHP indbygget, som folk kan bruge out of the box fordi der kun er
> en måde at skrive php-kode-i-hver-side baserede applikationer på.
>
> Med Perl er der mindst 10 forskellige måde at skrive webapplikationer
> på, personligt mener jeg at det er noget rod at putte al koden i
> templaten og mappe templaten direkte til url'en, men derfor er jeg
> også glad for at jeg ikke er låst til netop en løsning med Perl.

Ikke enig, ting kan også laves på flere forskellige måder i PHP også, dog
ikke lige så kort som f.eks. perls while(<>) og underforståede $_, hvis den
udelades, men du kan f.eks. variere et if/else statement med en switch, ræse
et array igennem med enten foreach, list & each eller noget helt andet.

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

---

jlouis@pc-011.diku.dk (Jesper Louis Andersen) writes:

> On Sun, 28 Sep 2003 19:06:22 +0200,
> Flemming Frandsen <ff-news.tiscali.dk@partyticket.net> wrote:
>
> > Når du rode med databaser er det stort set altid databasen der bruger al
> > cputiden, så det betyder ingen ting hvor hurtigt dit applikationssprog er.
>
> Yup, databaser er cpu-bundne.

Ja, lidt ligesom alle mail servere er...


--
Dennis
I have always thought explanations were overkill when correcting
mistakes. A simple "that's wrong" must suffice. I mean, people are
always aware why they are wrong. They just make mistakes to annoy you.

---

In article <x6ebrslp1t4.fsf@tyr.diku.dk>, Dennis Haney wrote:

>> Yup, databaser er cpu-bundne.
>
> Ja, lidt ligesom alle mail servere er...

Nej, de er I/O bundne, naar en af diskene er ved at staa af og
SCSI-kaeden hele tiden resetter. Naah, hvor var vi?

--
j.

---

jlouis@pc-011.diku.dk (Jesper Louis Andersen) writes:
> Flemming Frandsen <ff-news.tiscali.dk@partyticket.net> wrote:
>> * Der er mange rigtigt pæne moduler på CPAN <http://cpan.dk> som kan
>> stort set alt du har lyst til at kunne.
>
> Det ser jeg ikke som en fordel.

Du vil hellere skrive alting selv?

> Med maengden af crap der er i CPAN

Hvad for et kvalitetskriterie ville du bruge for at sortere crap fra?

> og hvor lidt forskellige pakker virker sammen er det en joke.

Jeg er ikke stødt på det problem. Eksempel?

> Derudover kommer problemet med at du for at anvende program X lige
> skal have 20 CPAN moduler.

Tjah.

>> * Hvis du skal udvide php skal du til at hakke i C sourcen som er
>> monolitisk.
>
> Men det her er en fordel. Du har pludselig en veldefineret graenseflade
> og undgaar selvsamme modulhelvede fra perl. Jeg vil tro at det er en
> af hovedaarsagerne til at PHP klarer sig.

Nonsens, PHP "klarer sig", fordi det altid er der, det er nemt at gå
til, og det løser de opgaver brugerne har. At ting er noget skrammel
har ikke noget med hvor populært det kan blive.

PHP har netop ikke en veldefineret grænseflade - diverse funktioner
bliver kun kompileret ind, hvis man eksplicit vælger dem under
installationen, f.eks. pg_* - dvs. man skal REINSTALLERE PHP hvis man
beslutter sig for at snakke med en PostgreSQL. Der er "modulhelvedet"
da klart at foretrække.
--
Lars Balker Rasmussen Consult::Perl

---

On Mon, 29 Sep 2003 10:29:36 +0200,
Lars Balker Rasmussen <lars@balker.org> wrote:
>
> Du vil hellere skrive alting selv?
>

I mange tilfaelde, ja. Jeg siger ikke at alt CPAN er crap, men meget
af det er.

> Hvad for et kvalitetskriterie ville du bruge for at sortere crap fra?

Tag et kig paa koden. Enten kan man se at modulet er velbearbejdet,
fornuftigt og daekker et passende omraade. Eller ogsaa kan man
se at lortet er skrevet af en der aldrig skulle have haft lov til
at producere et modul, og saa maa man igang med at skrive det selv.

>> og hvor lidt forskellige pakker virker sammen er det en joke.
> Jeg er ikke stødt på det problem. Eksempel?

Det mangler jeg saa paa staaende fod.

>> Derudover kommer problemet med at du for at anvende program X lige
>> skal have 20 CPAN moduler.
>
> Tjah.

Det har det problem at du ved at opgradere CPAN moduler kan smadre
nogle af dine applikationer, fordi ting nu ikke laengere virker
i en given situation.

> Nonsens, PHP "klarer sig", fordi det altid er der, det er nemt at gå
> til, og det løser de opgaver brugerne har. At ting er noget skrammel
> har ikke noget med hvor populært det kan blive.

Dybt enig.

> PHP har netop ikke en veldefineret grænseflade - diverse funktioner
> bliver kun kompileret ind, hvis man eksplicit vælger dem under
> installationen, f.eks. pg_* - dvs. man skal REINSTALLERE PHP hvis man
> beslutter sig for at snakke med en PostgreSQL. Der er "modulhelvedet"
> da klart at foretrække.

Nej, egentlig ikke. Der er ikke saa mange moduler man skal kompilere
ind at det skaber problemer, og _det_ falder i mange folks smag. Jeg
er enig med dig i at perl er et langt bedre vaerktoej end PHP, men
netop det som du diskrediterer PHP for her mener jeg ikke er det
der goer at det er daarligt.

Vi kan godt snakke om hvor tosset visse ting er lavet i PHP. Blandt
andet manglen paa et homogent interface til databaser (DBI, anyone?).
En anden tosset ting er at SQL-statements benytter ? som placeholders
for i statementet i stedet for :foo og :bar eller lignende. Og saa
videre.

Det jeg i virkeligheden efterlyser er kvalitet. Og der lever CPAN i
mange tilfaelde ikke op til mine krav. PHP har den fordel at du ved
at givent program X har en oevre graense for hvilke modulkrav det
kan saette. Hvilket IMHO giver det en fordel.

--
Jesper

---

Jesper Louis Andersen wrote:
> Det har det problem at du ved at opgradere CPAN moduler kan smadre
> nogle af dine applikationer, fordi ting nu ikke laengere virker
> i en given situation.

*Så* stort et problem er det vel heller ikke, hvis du ikke vil opdatere
din applikation, så er der vel ikke andet at gøre end at installere den
gamle version af modulet i et applikations-lokalt dir.


> Jeg er enig med dig i at perl er et langt bedre vaerktoej end PHP,
> men netop det som du diskrediterer PHP for her mener jeg ikke er
> det der goer at det er daarligt.

Hmm, så det du siger er at PHP er fleksibelt som en saltstang og komplet
som en McD menu og at "de uvaskede masser" bare vil have noget simpelt,
nu, ikke lære hvordan man gør det rigtigt fra starten af?


> En anden tosset ting er at SQL-statements benytter ? som placeholders
> for i statementet i stedet for :foo og :bar eller lignende. Og saa
> videre.

Hey, ?-placeholders er da ikke så tosset, det er jo såddan man gør langt
de fleste steder, det er langt fra den største hjerneblødning i PHP.


> PHP har den fordel at du ved
> at givent program X har en oevre graense for hvilke modulkrav det
> kan saette. Hvilket IMHO giver det en fordel.

Hmm, det er IMHO ikke en fordel, ihvertfald ikke hvis man skal lave
noget non-trivielt.

Der er en masse skod-php kode som folk genbruger, men fordi der ikke
findes et pakke system bliver fejl copy+pastet og glemt i stedet for at
blive udraderet af en ny version af pakken.

--
Regards Flemming Frandsen - http://dion.swamp.dk
PartyTicket.Net co founder & Yet Another Perl Hacker

---

Den Mon, 29 Sep 2003 10:20:54 +0000. skrev Jesper Louis Andersen:

> Vi kan godt snakke om hvor tosset visse ting er lavet i PHP. Blandt andet
> manglen paa et homogent interface til databaser (DBI, anyone?). En anden
> tosset ting er at SQL-statements benytter ? som placeholders for i
> statementet i stedet for :foo og :bar eller lignende. Og saa videre.
>
To hurtige kommentarer:
1) At bruge ? som joker, er en veldefineret standard -> se SQL92 og SQL99.
Her er det altså Perl, der er forkert på den!
2) Hvis du leder efter et homogent interface til databaser, kan du jo blot
hente DB-modulet fra Pear -> http://pear.php.net. Her findes efterhånden
også en righoldig samling komponenter, der er særdeles velskrevne.
Intentionen med Pear er, at det skal matche CPAN, dog med den forskel at
Pear er modereret - forhindrer situationen med CPAN.

Bortset fra dig kan jeg vældig godt lide, og anvender dagligt, begge
sprog. Man skal blot kende deres styrker og svagheder.

--
Hilsen/Sincerely, Michael Rasmussen

En windows admin er en person, for hvem den største bedrift er, at
lave konfiguration af serveren med trial and error via en gui.

---

Michael Rasmussen <mir@datanom.net> writes:

> Den Mon, 29 Sep 2003 10:20:54 +0000. skrev Jesper Louis Andersen:
>
> > Vi kan godt snakke om hvor tosset visse ting er lavet i PHP. Blandt andet
> > manglen paa et homogent interface til databaser (DBI, anyone?). En anden
> > tosset ting er at SQL-statements benytter ? som placeholders for i
> > statementet i stedet for :foo og :bar eller lignende. Og saa videre.
> >
> To hurtige kommentarer:
> 1) At bruge ? som joker, er en veldefineret standard -> se SQL92 og SQL99.
> Her er det altså Perl, der er forkert på den!

Ikke forstået. Jeg har altid brugt ? som placeholder i Perl/DBI, kan man
andet?

--
Kim Hansen | |\ _,,,---,,_ | Det er ikke
Dalslandsgade 8, A708 | /,`.-´` -. ;:-. | Jeopardy.
2300 København S | |,4- ) )-,_. ,\ ( `'-' | Svar _efter_
Tlf: 32 88 60 86 | '---''(_/--' `-'\_) | spørgsmålet.

---

Kim Hansen wrote:
>>1) At bruge ? som joker, er en veldefineret standard -> se SQL92 og SQL99.
>>Her er det altså Perl, der er forkert på den!
>
> Ikke forstået. Jeg har altid brugt ? som placeholder i Perl/DBI, kan man
> andet?

Jeg har også altid brugt ? som placeholder, men Oracle driveren har vist
support for såddan noget, jeg ved ikke om DBI understøtter det generelt.

--
Regards Flemming Frandsen - http://dion.swamp.dk
PartyTicket.Net co founder & Yet Another Perl Hacker

---

Michael Rasmussen wrote:

> 1) At bruge ? som joker, er en veldefineret standard -> se SQL92 og
> SQL99. Her er det altså Perl, der er forkert på den!

Huh? _ er default jokertegn i standard SQL, som % er det, ? og * er noget,
der spiller på M$ platformen.

mysql> select count(*) from djs where name like 'K?m Emax';
+----------+
| count(*) |
+----------+
| 0 |
+----------+
1 row in set (0.00 sec)

mysql> select count(*) from djs where name like 'K_m Emax';
+----------+
| count(*) |
+----------+
| 1 |
+----------+
1 row in set (0.00 sec)

> 2) Hvis du leder efter et homogent interface til databaser, kan du jo
> blot hente DB-modulet fra Pear -> http://pear.php.net. Her findes
> efterhånden også en righoldig samling komponenter, der er særdeles
> velskrevne. Intentionen med Pear er, at det skal matche CPAN, dog med
> den forskel at Pear er modereret - forhindrer situationen med CPAN.

Du skrev det, så behøver jeg ikke nævne det.

> Bortset fra dig kan jeg vældig godt lide, og anvender dagligt, begge
> sprog. Man skal blot kende deres styrker og svagheder.

samme her...

> En windows admin er en person, for hvem den største bedrift er, at
> lave konfiguration af serveren med trial and error via en gui.

Den har vi vist moret os over i news før, ik? Hvis du virkelig vil mobbe en
M$ admin, så gem hans mus

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

---

On Mon, 29 Sep 2003 10:29:36 +0200, Lars Balker Rasmussen
<lars@balker.org> wrote:

>dvs. man skal REINSTALLERE PHP hvis man
>beslutter sig for at snakke med en PostgreSQL. Der er "modulhelvedet"
>da klart at foretrække.

Med fare for at snakke php i d.e.p.p, så skal man blot lave/finde en
pgsql.so og tilvælge den i sin php.ini, eller indlæse den i runtime i
sit php-script.

(det er ikke ment som et forsvar eller deslige af PHP - blot en
bemærkning om at en hel reinstallation ikke er nødvendigt)

--
- Peter Brodersen

Ugens sprogtip: i dag (og ikke idag)

---

On Mon, 29 Sep 2003 10:20:54 +0000 (UTC), Jesper wrote:

>> Du vil hellere skrive alting selv?

> I mange tilfaelde, ja. Jeg siger ikke at alt CPAN er crap, men meget
> af det er.

>> Hvad for et kvalitetskriterie ville du bruge for at sortere crap
>> fra?

> Tag et kig paa koden. Enten kan man se at modulet er velbearbejdet,
> fornuftigt og daekker et passende omraade. Eller ogsaa kan man se at
> lortet er skrevet af en der aldrig skulle have haft lov til at
> producere et modul, og saa maa man igang med at skrive det selv.

Så er det vel idel lykke: Hvis du finder et godt modul, så bruger du
det, og ellers må du - som du oftest foretrækker; øverst - skrive et
ordentligt selv (som du så smider op på CPAN, så crap-o-meteret for
CPAN generelt falder).

Cool.


Mvh.

--
"Vi är små citroner" Adam Sjøgren
asjo@koldfront.dk