A stílus miatt nyomtam egy plusz 1-et, de annyit súgnék, hogy a gyengén típusos nyelvek - amilyen a PHP is - egyáltalán nem annyira hatékonyak.
A statikusan típusos nyelvek esetén végrehajtható egy rakás optimalizálás, ami miatt közel natív sebességű program fordítható belőlük. Ilyen a .NET (C#), Java, illetve tudtommal a Rust is. És természetesen ilyen a C és a C++ is, sőt ott még Garbage Collector sem áll a fejlesztő útjába :-).
A dinamikusan típusos nyelvek esetén, amilyen a Python, Ruby, JavaScript, stb viszont ezt nem lehet megtenni. Lényegében az van, hogy a legtöbb esetben a metódushívások, mező elérések esetén nem lehet elkerülni a név szerinti map-ből keresgetést. Sajnos ennek elvi korlátja van, hiába tettek bele közel végtelen sok munkaórát a JavaScript engine-ek optimalizálásába, ez a hátrány soha nem dolgozható le. (Ha be van vezetve a típusosság, és azt következetesen betartják a fejlesztők, és azt ki tudja aknázni a JIT compiler az más, de a projektek nagyon kis része ilyen.)
Ja, és a PHP alatt is Garbage Collector van, tehát ebből a szempontból sem jobb, mint a Java, vagy a .NET.
Ebben az esetben tehát a babzsák a PHP fejlesztőknél van, az ő programjuk lesz az erőforráspazarló™ modern™ megoldás™.
Ettől még igaz lehet, hogy a Java, vagy .NET fejlesztők gyakran óriási bloat-tengert állítanak elő, ezzel nem akarok vitatkozni. De a hiba nem a nyelvben van, hanem abban amit az eszközzel létrehoztak.
Hogy anekdotikus érvelést is adjak: egyszer írtam egy kis Java+Jetty alapú mini-weboldalt, amiben egy mini webchat-et valósítottam meg, illetve egy képre tudott több felhasználó egyszerre rajzolni. A PHP fejlesztő ismerősöm csak kamillázott, hogy hogy tudtam ilyen gyorsra csinálni? Pedig nem is gondolkodtam optimalizáláson, csak éppenhogy összeütöttem egy példaprogramot.
Valójában a nyers PHP is lehetett volna hasonlóan gyors, csak akik mindenféle framework™-öket használnak, azok sosem ismerik meg az eszköz valódi nyers teljesítményét. És ez is minden nyelvre igaz.
És igen, hallottam, hogy a Facebook is PHP-ban íródott. Éppen ezért ők is vért hugyoztak, hogy az interpretert részben compiláltra cseréljék, és optimalizálják. Ez csak azt mutatja, hogy az eszköz adta 1-10-100x-os nagyságrendő lassulás még mindig ellensúlyozható azzal, ha maga a program jól van megírva és nincsen benne skálázódási probléma (amikor a tárolt adatok számával rosszul szorzódik a végrehajtási idő).