Czy ma sens zmniejszanie PHP?

PHP jest kompilowane do kodu bajtowego, który jest następnie interpretowany na podstawie czegoś, co wygląda jak maszyna wirtualna. Wiele innych języków skryptowych stosuje ten sam ogólny proces, w tym Perl i Ruby. W rzeczywistości nie jest to tradycyjny język interpretowany, jak powiedzmy BASIC.
Próba „zminimalizowania” źródła nie powoduje efektywnego zwiększenia szybkości. Otrzymasz znaczny wzrost za pomocą

pamięć podręczna kodu bajtowego, taka jak APC
http://pecl.php.net/package/APC
.
Facebook wprowadził kompilator o nazwie

HipHop
http://github.com/facebook/hiphop-php/wiki
który konwertuje kod źródłowy PHP na kod C ++. Rasmus Lerdorf, jeden z wielkich ludzi PHP, tak zrobił

prezentacja dla Digg na początku tego roku
http://talks.php.net/show/digg
który obejmuje ulepszenia wydajności podane przez HipHop. Krótko mówiąc, nie jest to dużo szybsze niż optymalizacja kodu i użycie pamięci podręcznej kodu bajtowego. HipHop to przesada dla większości użytkowników.
Niedawno wprowadzono również Facebook

HHVM
https://www.facebook.com/note. ... 28920, nowa maszyna wirtualna oparta na ich pracy nad stworzeniem HipHop. Wciąż jest całkiem nowy i nie jest jasne, czy będzie stanowił istotny impuls dla ogółu społeczeństwa.
Aby upewnić się, że jest to wyraźnie określone, przeczytaj

ta prezentacja
http://talks.php.net/show/digg
całkowicie. Wskazuje na wiele sposobów testowania i profilowania kodu oraz identyfikowania wąskich gardeł za pomocą narzędzi takich jak

xdebug
http://xdebug.org/
i

xhprof
http://pecl.php.net/package/xhprof, także z Facebooka.

Porzuć ideę kompresji PHP na rzecz użycia pamięci podręcznej kodu operacji, takiej jak

PHP Accelerator

http://en.wikipedia.org/wiki/PHP_accelerator
lub

APC

http://pecl.php.net/package/APC
.
Albo coś innego

memcached

http://memcached.org/

Przy pewnym przepisywaniu (krótsze nazwy zmiennych) można zaoszczędzić kilka bajtów pamięci, ale jest to również bardzo ważne.
Jednak niektóre z moich aplikacji projektuję w taki sposób, aby mogły łączyć w pakiety skrypty. Dzięki

php -w

można to znacznie skrócić, dodając niewielkie przyspieszenie uruchamiania skryptu. Jednak w operacjach obsługiwanych przez serwer oszczędza to tylko kilka sprawdzeń czasu modyfikacji plików.

To nie tyle odpowiedź, ile reklama. Pracuję nad rozszerzeniem PHP, które tłumaczy instrukcje Zend do pracy na statycznie wpisanej maszynie wirtualnej. Nie przyspiesza działania dowolnego kodu PHP. To naprawdę pozwala na pisanie kodu, który jest znacznie szybszy niż pozwala na to zwykły PHP. Kluczem jest tutaj statyczne pisanie. Na nowoczesnych procesorach język dynamiczny zjada kary za błędną interpretację lewej i prawej gałęzi. Fakt, że tablice PHP są tablicami mieszającymi, również pociąga za sobą wysokie koszty: wiele błędnych przewidywań dotyczących gałęzi, nieefektywne wykorzystanie pamięci podręcznej, słabe wstępne pobieranie pamięci i brak optymalizacji SIMD. W szczególności błędne przewidywania branżowe i chybienia w pamięci podręcznej są piętą achillesową nowoczesnych procesorów. Moja mała maszyna wirtualna omija ten problem, używając typów statycznych i tablicy C zamiast tabeli skrótów. Rezultat jest około dziesięć razy szybszy. To jest użycie interpretacji kodu bajtowego. Rozszerzenie może opcjonalnie skompilować funkcję za pomocą gcc. W takim przypadku prędkość jest od dwóch do pięciu razy większa.
Oto link dla wszystkich zainteresowanych:
https://github.com/chung-leong/qb/wiki
https://github.com/chung-leong/qb/wiki
Ponownie, rozszerzenie nie jest ogólnym akceleratorem PHP. Musisz napisać odpowiedni kod.

Tak, jest jeden punkt (nietechniczny).
Twoja firma hostingowa może szpiegować Twój kod na swoim serwerze. Jeśli się zmniejszysz i oszpecisz, szpiegom będzie trudniej ukraść twoje pomysły.
Jednym z powodów, dla których php staje się coraz mniejszy i brzydszy, może być ochrona przed oprogramowaniem szpiegującym. Myślę, że brzydki kod powinien zrobić jeden krok w automatycznym wdrażaniu.

Istnieją kompilatory PHP ... aby zobaczyć listę

to poprzednie pytanie
https://coderoad.ru/621502/
; ale (chyba że jesteś wielkości Facebooka lub kierujesz swoją aplikację tak, aby działała po stronie klienta), są one o wiele bardziej kłopotliwe niż kosztują
Proste buforowanie kodu operacyjnego zapewni większą wartość Twojego wysiłku. Lub sprofiluj swój kod, aby zidentyfikować wąskie gardła, a następnie zoptymalizuj go.

Nie musisz zmniejszać PHP.
Aby uzyskać najlepszą wydajność, zainstaluj pamięć podręczną kodu operacji; ale idealnym rozwiązaniem byłaby aktualizacja PHP do wersji 5.5 lub nowszej, ponieważ nowsze wersje mają domyślną pamięć podręczną kodu operacji o nazwie Zend Optimizer, która działa lepiej niż inne

http://massivescale.blogspot.c ... .html
http://massivescale.blogspot.c ... .html
.