Do dzisiejszego porównania wykorzystamy PHP w wersji 8.2 oraz NodeJS w wersji 18.14.0 LTS. Użyjemy również Docker, aby ułatwić sobie konfigurowanie środowisk. Oczywiście wszystko starałem się trzymać w najbardziej defaultowej wersji jak tylko mogłem, więc nie uświadczymy tutaj żadnych dodatkowych konfiguracji, które mogłyby „podboostować” którąkolwiek technologię.

Dzięki lekcji, którą wyciągnąłem podczas tworzenia poprzedniego porównania, dowiedziałem się, że testy muszą być jeszcze prostsze i bardziej uniwersalne i oto doszedłem do wniosku, że najlepiej będzie zainicjować następujące sprawdziany:

1. Obliczenie 20! czyli silnię z 20. Oczywiście rekurencją, aby było dodatkowe obciążenie.
2. Znaleźć największą liczbę z przedziału 1-100000 – generowanie tablicy oczywiście poza mierzeniem czasu.
3. Wygenerowanie losowego ciągu znaku o długości 100000 znaków i przekształcenie wszystkich liter na wielkie litery.

Zadania może nie są aż nadto trudne, ale są wystarczające, aby ukazać konkretne czasy wykonania. Ważne też jest przy każdym teście, aby wyniki były po prostu przyzwoite – to nam powie czy daną technologię w ogóle brać za poważny wybór.

Tworzenie kodu

Na szczęście nie musiałem spędzić wielu godzin nad tym wszystkim, a i samo wyszukanie potrzebnych informacji dla obu narzędzi było bardzo przyjemne i bardzo proste. Powiem, że na tym polu mamy ładny remis. Co ciekawe, najwięcej problemów miałem z Dockerem. To nie tak, że to było uwłaczające i mega trudne, po prostu zapomniałem jak go się nastawia 😅. Także mogę powiedzieć, że taki minimalny problem był z Dockerem, no ale to nie o nim miałem pisać 😉

Wyniki

Muszę uprzedzić, że wyniki są nawet ciekawe. Żadna z technologii nie jest słaba i stanowią nadal dla siebie konkurencję. Jak dla mnie oba narzędzia dały sobie świetne radę. Liczby mówią same za siebie:

Podsumowanie

Wyniki są bliskie siebie i wydawać się może że PHP jest 2x razy szybszy od Node.js, ale czy tak jest przy większych projektach? Nie wiem, bo te testy tego nie ukazują. To co wiem, to oba narzędzia są jednak wydajne i tylko różnice technologiczne powinny decydować o tym, które narzędzie wybierzemy 🙂

Wszystkie testy oraz konfiguracja Docker dostępne są na GitHub

Cześć moje słonie kochane 🐘 i węże tuląco-jadowite 🐍. Nadszedł ten wiekopomny moment (do którego mnie zmusiliscie) do którego zostałem bardzo zachęcony, w którym napiszę o tym co jest lepsze: PHP czy Python?

Już na wstępie powiem, że żadne w powyższych, bo prawdziwy programista powinien umieć kontrolować wszystkimi napięciami, które powstają w komputerze tak, aby tym pisać m.in kod binarny, ale i też sterować każdym podzespołem. Wszystko inne to języki wyższych poziomów – tego pogrubionego fragmentu jak to coś nie brać na poważnie 😆

Więc… dzisiaj pomimo tego, że coś tutaj ukażę to niekoniecznie będzie to świadczyć o tym, który z tych języków będzie lepszy. Języki programowania są tylko różnymi narzędziami i bardzo łatwo je porównać do śrubokrętów, które powstały do konkretnych typów wkrętów (na internecie wpisać „typy śrubokrętów” to świadomość wskoczy na wyższy lvl) albo do różnych typów klejów, bo są takie do kartek, a inne są do tapet (też różne rodzaje), a jeszcze inne kleje są do drewna itd. itd… No tak samo są różne naczynia.. dobra chyba nie muszę dalej porównywać czegoś nierealnego z realnymi przedmiotami 🤣

Przygotowanie

Aby cokolwiek móc przetestować, należy wymyślić jak coś przetestować i takie punktowe cusie, np. lista rzeczy do przetestowania, ma nam też coś powiedzieć i to nie jest wcale takie proste, zatem uznałem, że nie będę robić wyrafinowanych testów lecz przetestuję jakieś rzeczy, które w obu językach da się prosto utworzyć i uruchomić.

Mój test polegać będzie na pobraniu z jednego źródła danych (z pliku lokanego) dokumentu w formacie JSON, a następnie sprawdzić:

1. Prędkość parsowania JSON na Obiekt
2. Szybkość z jaką połączy się wszystkie elementy z tablicy za pomocą pętli i konkatenacji (nie będę korzystać ze specjalnych metod służących temu)
3. Szybkości serializacji JSON do obiektu klasy DTO
4. Tak jak 3. tylko że będę chciał uzyskać błąd i przetestować szybkość obsługi wyjątku
5. Prędkość deserializacji z DTO na JSON i utworzeniu nowego pliku dokumentu JSON – z tego zrezygnowałem (wyjaśnię później)

Więc co nam to udowodni? Oprócz tego że będę mógł zdać relację pisania obu skryptów to i też poznamy prędkości.

Do testów użyję PHP 8.2 oraz Python3. Każdy punkt zrealizuję jako osobny plik, a całość wrzucę na GitHub, abyście mogli mój test powtórzyć no albo czegoś się nauczyć albo przerobić pod własne testy.

O pisaniu skryptów

W obu przypadkach googlowałem proste rzeczy, a jak to pobrać dane z pliku, a jak to przerobić na JSON, a jak to mierzyć czas wykonania kodu. No i tutaj generalnie w obu językach nie miałem aż tak większego problemu, aby cokolwiek znaleźć. Z Pythonem miałem problem taki, że kompletnie jego składni nie znam, a nawet myślałem, że skoro średników nie trzeba to tym bardziej jakiś dwukropków i „selfiaków” nie będę potrzebować, więc problemy były ze nieznajomością narzędzia. Z tego powodu musiałem zrezygnować całkowicie z piątego punktu testu.

Co do PHP, generalnie poza drobnymi zmianami w nazwach zmiennych to większość kodu była kopiuj wklej z internetu. Struktury w obu językach staram się zrobić identico (z drobnymi różnicami w składniach). Więc jak w PHP zrobiłem foreach to na internecie szukałem odpowiednika dla Pythona i znalazłem for in.

Bardzo ważne było też dla mnie to, aby skrypty w obu językach wyglądały bardzo podobnie, aby w łatwy sposób dało się porównać co z czym jak szybko działa. Pisanie kodu zacząłem wczoraj (20 list 2022) o godzinie około 20:00 co z PHP skończyłem o 20:30, co jak z Pythonem zacząłem koło 21:00 to skończyłem o 23:30 i powiedziałem, że to nie jest język na moje nerwy.

Porównanie

Jako iż jestem jeszcze przed analizą wyników na wstępie mogę powiedzieć co wydaje mi się, a wydaje mi się, że Python jest dużo wolniejszy od PHP no i tak, bo w PHP można przeiterować 5-cio-milionową elementów tablicy w miej niż sekundę używając tylko bardzo prosty foreach, co w Pythonie, aby takie samo zrobić wydajniej trzeba napisać jednak więcej kodu, ale bez kombinacji w kodzie jednak chciałem robić porównanie, no bo foreach i for in to dla mnie i pewnie dla wielu to samo i w założeniu działać ma tak samo.

Gdy miałem przygotowany 30 MB plik z danymi to PHP poradził sobie ze wszystkim, a Python drugiego punktu testu nie potrafił dokończyć w rozsądnym czasie. Tak w sumie przerwałem mu działanie po 2 minutach. PHP poradził sobie poniżej 1 sekundy (a dokładniej to w 0,199593… sek) tworząc zmienną ze 16968000 znakami.

No ale chciałem jednak dać szansę wężowi, aby nie było, że specjalnie na start go uwaliłem. No chociaż myślę, że język programowania, który jest tak długo „wspierany” i uznawany jest za język wysokiego poziomu powinien mieć w miarę dojrzałą formę foreach (nawet ten for in) tak, aby zawsze szybko to działało i już na tym etapie nasuwa mi się wniosek, że to nie jest język, w którym cele biznesowe da się osiągnąć stosując strukturę heksagonalną i wszelakich zasad programowania domenowego, i jeszcze aby to działało optymalnie. Zasada jest prosta: 20 mln itemów w tablicy i chcę je przeiterować. Dla mnie według zasady KISS powinienem był użyć tylko i wyłącznie foreach.

Zatem.. zmniejszyłem rozmiar pliku z danymi do około 300 KB (dużo dużo mniej) i dostałem następujące wyniki

Wnioski

Trudno tutaj jednoznacznie powiedzieć że Python jest gorszy, bo mój test tego nie dowodzi. Raz że musiałbym ten język lepiej poznać to dwa w nim tak ja ja to zrobiłem nie pisze się. To co już jednak ustaliłem, że PHP działa jednak dużo szybciej niż zakładałem 😅 W wersji 5.4 takich czasów bym już nie uzyskał, więc widzę duży postęp w optymalizacji tego języka, co pewnie skłoni mnie do porównania prędkości pomiędzy wersjami, a co bardziej, bym miał kolejny powód do aktualizowania wszystkiego 😈

Jeśli chodzi o jakieś dalsze wnioski idące za zdobytymi przeze mnie cyferkami to zostawię wam moje misiaczki pole do popisu, bo może jest coś, co ja mogłem przeoczyć… na pewno jest 😆

Podsumowanie

Zatem poświęciłem dwa wieczory specjalnie pod ten pseudo-naukowy wyczyn, który zasadniczo mało co udowadnia. Za to mogłem ujrzeć wężowy odwłok odchodzący ku zachodzącemu słońcu na tle słoniowych chmur.. Czy straciłem czas?… 😬 Powiem tylko, że czas poświęconych dla moich kochanych misiaczków nigdy nie jest stracony 🫂

Wolę PHP

Także do następnego miłego 😘

Repozytorium: https://github.com/EnterVPL/PHPvsPython

Cześć kociaczki, psiaczki i miłe zwierzaczki 😀 Dzisiaj porozmawiamy sobie tak ogólnie o bibliotece do języka PHP Guzzle Promises.

Pewnie część z tych co znają język JavaScript kojarzą taki twór jak Promise czyli tzw. Obietnicę. Do jej szybszej obsługi nawet wprowadzono w tym języku async i await co już na mówi po części do czego to służy. Tak: do asynchroniczności 😄

Jak wiadomo PHP nie jest językiem, który posiadałby asynchroniczność, ale to nie zraziło twórców Guzzle, która służy do obsługi requestów i pewnego dnia utworzyli oni Promises, aby można było obsłużyć asynchroniczne requesty – czyli taki PHPowy odpowiednik fetch znanego z JS. Jak się potem zaczytałem, to można ich Promise używać nie tylko do requestów, co mnie w sumie cieszy, bo dzięki temu możemy nasz kod wzbogacić o wiele ciekawszych mechanizmów.

Quick Start został opisany na ich repozytorium GitHub w pliku Readme.md – ja tylko przełożę część występujących tam przykładów.

Podstawy – przykłady

Utworzenie Promise

use GuzzleHttp\Promise\Promise;

// Tworzymy nasz Promise
$promise = new Promise();

// i ustalamy co ma się wykonać
// metoda then() przyjmuje dwie funkcje
// pierwsza funkcja wykonuje się gdy nie napotkamy błędów
// druga wykona się jeśli zostaną napotkane błędy/wyjątki
$promise->then(
    // $onFulfilled
    function ($value) {
        echo 'The promise was fulfilled.';
    },
    // $onRejected
    function ($reason) {
        echo 'The promise was rejected.';
    }
);
// oba argumenty funkcji then musza być typu callable:
// @see https://www.php.net/manual/en/language.types.callable.php

Rozwiązanie Promise

Aby nasz Promise cokolwiek wykonał musi zostać rozwiązany, jest to dosyć proste, bo wystarczy to zrobić:

use GuzzleHttp\Promise\Promise;

$promise = new Promise();
$promise
    ->then(function ($value) {
        // ten then() zwróci wartość, ale nie przerwie łańcucha wywołań then()
        return "Hello, " . $value;
    })
    // jak widzisz then() zwraca nowy Promise. Ten jako $value będzie miał to co zwrócił poprzedni then()
    ->then(function ($value) {
        echo $value;
    });

// Rozwiązanie Promise
$promise->resolve('reader.')
// wyświetli się "Hello, reader."

Ok pomyślmy co tutaj się stało 🤔 Mamy jeden zadeklarowany Promise, który ma 2x then().

Jeśli Promise nie jest rozwiązany to każdy then() zwraca nowy Promise, dzięki czemu możemy tworzyć taki łańcuch. Dla tych co chcą bardziej wiedzieć jak ten kod działa to zapraszam na GitHub: https://github.com/guzzle/promises/blob/8e7d04f1f6450fef59366c399cfad4b9383aa30d/src/Promise.php#L31 – specjalnie dla was to znalazłem 😁

Więc póki nasz Promise jest w oczekiwaniu to możemy mu dokładać coraz to bardziej kolejne then(), a w nich każde kolejne callable (czyli tak w sumie callbacki), a każdy kolejny callable będzie miał jako wartość argumentu to co jest zwracane w poprzednim callable.

W pierwszym then() mamy funkcję zwracającą połączenie „Hello, ” z podaną mu wartością. W kolejnym then() jako wartość argumentu mamy poprzednio zwróconą wartość. Z tego przykładu wiemy że to będzie w całości string (bo tak zadziała PHP w tym przypadku). Nasz drugi then() wyświetli tą wartość.

Więc to co się dzieje po $promise->resolve(’reader.’) to ten „reader.” jest przekazywany do pierwszego then(). On łączy „Hello, ” z „reader.” i to jest przekazywane do kolejnego then() i on ma do wykonania wyświetlenie już wcześniej połączonego napisu co po prostu pokaże nam „Hello, reader.”

Proste? Tak? 😅 Wiem, że nie dla każdego to się wydaje intuicyjne, ale kilka prób i okaże się, że to banał.

Promise Forwarding

Tak do końca nie wiem jak to poprawnie na Polski przetłumaczyć, no może przekazywanie obietnic ma tutaj jakiś sens, ale nie będę szukać na siłę 😉

W skrócie: możemy zadeklarować kilka obietnic i je zwracać w then() dzięki temu mamy wpływ na to, kiedy i którą obietnicę będzie można wywołać. W tym prostym przykładzie poniżej wykonamy je jedna za drugą, ale nic nie stoi na przeszkodzie, aby pomiędzy rozwiązaniami wstawić jakiś inny kod.

use GuzzleHttp\Promise\Promise;

$promise = new Promise();
$nextPromise = new Promise();

$promise
    ->then(function ($value) use ($nextPromise) {
        echo $value;
        return $nextPromise;
    })
    ->then(function ($value) {
        echo $value;
    });

// Rozwiązujemy nasz pierwszy callback. Wyświetli się 'A'
$promise->resolve('A');

// tutaj może być inny kod

// Rozwiązujemy nasz drugi callback. Wyświetli się "B"
$nextPromise->resolve('B');

Synchroniczne wywołanie

Czasami (tak jak czasami w JS i innych językach bywa) mamy możliwość czekania na wykonanie się obietnicy. Czy to jest przydatne? No czasami tak, ale tutaj nie będę się nad tym rozwodzić.

Metoda wait() domyślnie rozwiązuje nam Promise i dodatkowo zwraca nam wartość z callbacka:

use GuzzleHttp\Promise\Promise;

$promise = new Promise(function () use (&$promise) {
    $promise->resolve('foo');
});

// metoda wait() wymusza czekanie na rozwiązanie się Promise
echo $promise->wait(); // wyświetli "foo"
// i dopiero wtedy zacznie iść do dalszej części kodu

Podsumowanie

Dzisiaj poznaliśmy coś co w PHP było uznawane za niemożliwe, a jednak dzięki bibliotece Guzzle/Promise niemożliwe staje się możliwe, a PHP dzięki temu staje się asynchroniczny! Oczywiście to nie jest nic nowego, bo pierwsze wzmianki, które znalazłem są z 2015 roku, w którym pojawiła się wersja 0.1 tego zasobu.

Na stan dzisiejszy jest to dość mocno rozwinięty projekt, który cieszy się coraz większym poparciem. Ja o niej dowiedziałem się stosunkowo niedawno, co mi trochę wstyd za to, no ale lepiej później niż wcale, a świat bibliotek i dokumentacji jest ogromny 😄

Mam nadzieję, że pomogłem tym wpisem i że więcej PHP deweloperów z tego skorzysta.

Przytulam i trzymajcie się ciepło. Ciao 😊