Je rychlejší web v PHP 7 nebo Pythonu 3?

Nejsem si jist jak PHP (myslím že taky ne), ale Python nemá tail-recursion optimalizaci a ani se neplánuje. Tím trpí u těch vyšších hodnot. Pokud člověk píše v Pythonu a chce výkon, takovému kódu se vyhne. Takže by bylo zajímavější udělat test s něčím, co se pak skutečně používá. :-)

Testovat se musí umět. Obávám se, že jen naprosté minimum webových aplikací potřebuje hrubou výpočetní sílu v integer počtech. Takže se vlastně testovalo něco, co ve webových aplikacích nemá téměř žádné uplatnění.

Je to něco jako kdybyste testoval rychlost auta podle toho, ve kterém modelu auta lze rychleji zašroubovat víčko od nádrže - určitě to bude velice určující pro to, které auto si vybrat.

#1 Michal Hořejšek: #2 Václav Havel: Ta rekurze je tam naschvál, je to snaha o simulaci určité práce v aplikaci. Mohl bych tam samozřejmě přidat práci s databází, ale tím by to přestalo být testem jazyka.

Aby se nejednalo jen o test hrubé výpočetní síly, tak se ptáme postupně na jednotlivá čísla posloupnosti. Pro první čísla je výpočet posloupnosti úplně zanedbatelný a měříme tak vlastně jen rychlost startupu, frameworku a renderování šablon. S rostoucím číslem se čím dál více testuje rychlost volání funkcí v jazyce.

Zkusil jsem schválně ten algoritmus přepsat na iterativní a výsledek je: PHP okolo 200 dotazů/s, Python okolo 3000 dotazů/s. Tady zase imho měříme jen startup aplikace (FCGI vs WSGI), takže to také moc komplexní test není.

Byla u php zapnutá OpCache s nastavením opcache.validate_timestamps = Off?

Standardní Python je IMHO nejpomalejší interpretr programovacího jazyka široko daleko ze všech programovacích jazyků co znám (a znám jich kolem stovky). To, že je schopen přesto rychlostně soupeřit s PHP říká něco nelichotivého o PHP.

PHP je neefektivně řešeno tak, že každý request musí znovu vybudovat veškerý kontext včetně objektů a dalšího znovu od nuly. Dokonce pokaždé request znovu překládá zdrojový kód do p-kódu. Drobné výjimky pomiňme, protože nestojí prakticky za řeč. To je tak velký overhead při requestu, že nikdo soudný nebude dělat zatěžovanější weby přímo v PHP. (Pokud nepoužije třeba konvertor PHP -> C++ ála facebook - zde ale výsledek už neběží v PHP runtime, a jsme zcela jinde.)

Autoři PHP záměrně vykastrovali PHP proto, aby mohli bokem přivydělávat na nástrojích, které mají jiné jazyky ve vínku a zdarma.

Normální princip webu, který dělá Python, Java, a další přirozeně je nebudovat všechno znovu od nuly při každém requestu. Zdrojáky se nekompilují při každém requestu, řada objektů žije a uchovává se i mezi requesty, různé requesty sdílejí určitou sadu objektů a proměnných, a mnohé další. Tím je cena za request mnohem levnější než u PHP.

PHP má také řadu nectností dalších: Například mizernou práci s řetězci, dokonce tak mizernou, že nemá žádný základní datový typ pro řetězec. To, co PHP nazývá "string" je jen sekvence holých bajtů. Práci s řetězci si pak můžete nasimulovat pomocí knihoven. Porovnejte s luxusní prací s unicode řetězci přímo v Pythonu. Programovací jazyk bez řetězců - to je muzeální vykopávka patřící do doby ENIACu.

Každý webový projekt, který si zvolil PHP a trochu se rozrostl, řeší brutální výkonové problémy. Taková wikipedie si de facto totálně překopala zdrojáky PHP a šíleně je zoptimalizovala, a i tak má několikanásobek serverů, než by na stejné zatížení potřeboval stejný projekt v jiném jazyce. Facebook nakonec naprogramoval kompilátor PHP -> C++, jinak by se asi Zuckenberg už dávno oběsil.

Je naprosto k ničemu, že PHP optimalizuje výkon základní integer aritmetiky, když to celé zabije příšernou cenou za request a dalšími neefektivitami.

Kdybyste porovnával PHP s něčím jiným, než nejpomalejším mainstreamovým jazykem na světě Pythonem - PHP by dostalo daleko více na zadek. Takový web třeba v Javě by natřískal PHP a nechal ho daleko za sebou nejen v rychlosti requestu, ale i v té integer aritmetice.

Zkrátka dokud PHP bude držet šílenou cenu za request, na výkon to nebude. Vzhledem k tomu, že PHP tu je už velice dlouho, a navíc už ve verzi 7 - tak se nejspíše nic nezlepší ani příštích 30 let v PHP. Šílený overhead při request strašně žere výkon i paměť, několikanásobně více, než jakékoli jiné webové řešení. Protože většina webových requestů je light, tedy mnoho toho nedělá, max. vyzvedne data z optimalizované databáze a nějak je zobrazí, pak cena za request je určující pro výkon celého webového sídla.

Byla u PHP zapnutá opcode cache? Dělat jakékoliv benchmarky bez toho je nesmysl, protože komu jde o výkon, tak si to zapne.

#5 Václav Havel: Facebook už kompilaci z PHP do C++ už dávno nedělá. Používá teď HHVM, což je JIT kompilátor.

#5 Václav Havel: php má opcode cache jako standardní součást už asi 6 let.

#4 karl: #6 Jakub Vrána: Ano, opcode cache byla zapnutá.

Zkusil jsem nastavení opcache.validate_timestamps = Off, ale velké zrychlení to nepřineslo, pouze jednotky dotazů navíc.