W miarę jak człowiek pewne rzeczy sobie chce zautomatyzować, przychodzi pora na korzystanie z PHP z linii poleceń.

Zauważyłem jednak, że binarka php.exe po odpaleniu z konsoli pod Windows ma jakiegoś 3-sekundowego laga. Przekopałem trochę Sieć i znalazłem info, że takie zachowanie powoduje php_curl.dll. Wyłączyłem to rozszerzenie i interpreter zaczął pod konsolą zasuwać jak młody źrebak.

Sobie poradzę, jak zajdzie potrzeba korzystania z cURLa (pakiet msys), ale jest ktoś w stanie wyjaśnić, dlaczego akurat to rozszerzenie (ponoć w połączeniu z natywnym rozszerzeniem MySQL) powoduje takie lagowanie?

Nie znalazłem jakiegoś szczegółowego info, ale pytam, co w sytuacji, gdy będę potrzebował cURLa spod konsoli? Jedyne info, jakie znalazłem, to wiszący bug sprzed ~3 lat.

Używałem wielokrotnie curl'a w "konsoli" i nie miałem problemów.

Jednak powiem, że php jest mało wydajne jeżeli o curl chodzi - dlatego postanowiłem aplikację napisać w c++ i zamiast ~4 zapytań na sekundę wyszło nagle koło ~20

Z jaką wersją php próbowałeś? Czy dzieje się tak tylko na windowsie? Czy na próbowałeś na innym systemie? Jeżeli tak to czy konfiguracja i wersja php były takie same?

Jak będziesz potrzebował curla możesz przecież uruchomić PHP z innymi ustawieniami i curlem włączonym.

Tylko i wyłącznie na Windows się coś takiego dzieje; niezależnie od wersji interpretera, czy systemu. Nie pamiętam konkretnego linka (i nie mogę go teraz odkopać), ale z tego co pamiętam, to lagowanie procesu zdarza się w sytuacji, gdy jednocześnie jest ładowane php_curl i php_mysql w konfiguracji interpretera.

Wyłączyłem php_curl (bo tego nie używam w konsoli, konteksty przy I/O rządzą ;P) i zaczęło działać jak na systemach POSIX-owych - bez żadnych opóźnień.

Równie dobrze bez CURL możesz jechać rzucając nagłówkami HTTP ;p

PHP nie był, nie jest i NIE BĘDZIE magiem szybkości. Odkąd zainteresowałem się tworzeniem aplikacji desktop'owych w C# zmieniłem zdanie co do PHP - jak najmniej, ogłupia ten język. Co w konsoli to c++ lub c# W PHP miałem kilka aplikacji, które działały pod konsolką ale to wynikało z mojego lenistwa - nie chciało mi się szukać dokumentacji i implementacji libcurl w c++.

Czytaj ze zrozumieniem, o czym piszę. Nie wspomniałem ni słowem o szybkości interpretera ogólnie, tylko w konsoli na jednej konkretnej platformie. Oraz o bibliotece, która spowodowała opóźnienie w - prawdopodobnie - zwalnianiu pamięci procesu. I do tej pory nie wiem, co jest nie tak, że akurat te dwa rozszerzenia się gryzą.

Zaznaczę jeszcze raz: problem występuje tylko na jednej platformie i tylko z konkretnym rozszerzeniem oraz nie ma nic wspólnego z szybkością całego języka.