[Conny Westh]

Jag testkörde SimonPs kod (på en betydligt långsammare maskin) och fick följande resultat:

Non OOP Result: 2.6286079883575 seconds
OOP Result: 5.3388919830322 seconds

Jag noterar att Simons Ratio (ImperativeTime/OOPtime) blev 2,88 medan min blev 2,03, det har m a o ganska stor betydelse vilken maskin man kör på.

Sen har det alltid varit så att OOP körningar tar något längre tid eftersom det är mer att göra för systemet. Det är inte av prestandaskäl man väljer OOP i stället för imperativa språk, det är för att kunna hantera komplexitet på ett bättre sätt och minska risken för buggar, återanvändbarhet av tidigare kod, samt därmed kortare utvecklingstid. Maskiner blir ständigt snabbare så hastigheten är inte det avgörande i de flesta fall. PHP ger i sig prestandaförluster i och med att det dessutom är interpreterande och inte kompilerande. Är hastigheten en kritisk faktor så väljer man ett annat språk.

[SimonP]

Ursprungligen postat av ConnyWesth

Sen har det alltid varit så att OOP körningar tar något längre tid eftersom det är mer att göra för systemet. Det är inte av prestandaskäl man väljer OOP i stället för imperativa språk, det är för att kunna hantera komplexitet på ett bättre sätt och minska risken för buggar, återanvändbarhet av tidigare kod, samt därmed kortare utvecklingstid. Maskiner blir ständigt snabbare så hastigheten är inte det avgörande i de flesta fall. PHP ger i sig prestandaförluster i och med att det dessutom är interpreterande och inte kompilerande. Är hastigheten en kritisk faktor så väljer man ett annat språk.

Jag ville mest belysa prestandaproblem som OOP ger i vissa undantag. Jag har upplevt samma sak i kompilerande språk, t.ex C/C++, dvs. att OOP ger en försämring i prestanda vid intensiva anrop, inte lika mkt som PHP men ändå märkbar.

[danjel]

Ursprungligen postat av ConnyWesth

.... PHP ger i sig prestandaförluster i och med att det dessutom är interpreterande och inte kompilerande. Är hastigheten en kritisk faktor så väljer man ett annat språk.

Nja, det stämmer inte. De flesta trafikintensiva använder någon slags bytecode cache för prestanda.


Vad gäller detta test, intressant vore se vilken skillnad det blir om man använder statisk metoder istället för instansiering. Förmodligen lite mindre minnesutnyttjande, vilket ju blir lite mer "rättvist" eftersom oop gör lite mer än funktionella koden om den instansierar

[Conny Westh]

Ursprungligen postat av danjel

Nja, det stämmer inte. De flesta trafikintensiva använder någon slags bytecode cache för prestanda.


Vad gäller detta test, intressant vore se vilken skillnad det blir om man använder statisk metoder istället för instansiering. Förmodligen lite mindre minnesutnyttjande, vilket ju blir lite mer "rättvist" eftersom oop gör lite mer än funktionella koden om den instansierar

Nej, bytecode cache (som ju sker i runtime eller är det JIT Compilation du menar) kan aldrig mäta sig med kompilerad kod (som ju förkompilerar och optimerar koden).

Stark typning kan i många programspråk ge 50-100 gånger prestandaförbättring även i en interpreterande eller semikompilerad miljö.

Dock helt riktigt att statiska metoder ger betydande prestandaförbättring i OOP-sammanhang jämfört med instansiering, men det beror på vilket problem man ska lösa om man kan använda det eller inte.

[danjel]

Med bytecode caches så kompileras och parsas koden endast vid första request. Så den overhead som JIT kompilering ger per default i PHP kan alltså undvikas.

Jag invände mot att du sa : om hastighet är en kritisk faktor så väljer man ett annat språk. Om man gör extremt stora beräkningar m.m i kod så är det klokt att inte använda php, t.ex motsvarande detta performance test i denna tråd. Där skulle asp.net eller cgi/c++ "vinna".
Det jag menar är att generellt väljer man inte bort php pga sämre prestanda i webblösningar.

[Clarence]

Ursprungligen postat av danjel

Med bytecode caches så kompileras och parsas koden endast vid första request. Så den overhead som JIT kompilering ger per default i PHP kan alltså undvikas.

Jag invände mot att du sa : om hastighet är en kritisk faktor så väljer man ett annat språk. Om man gör extremt stora beräkningar m.m i kod så är det klokt att inte använda php, t.ex motsvarande detta performance test i denna tråd. Där skulle asp.net eller cgi/c++ "vinna".
Det jag menar är att generellt väljer man inte bort php pga sämre prestanda i webblösningar.

Med bytecode caches sparas en cachad bytecode, det är inte maskinkod. När man pratar om JIT-kompilation så brukar det vara precis samma situation, men resultatet är maskinkod istället för bytecode. Därför diskuteras det och utvecklas det JIT kompilatorer för PHP, för att det skulle ge en relevant prestandavinst.

Annars håller jag med dig om att man generellt sätt inte väljer bort PHP av prestandaskäl. Förutom vid väldigt speciella applikations-typer, t ex en chat eller annan websockets-hantering - och då är inte anledningen exekveringstiden.