Witam, który warunek jest szybszy:
if ( is_array($tablica) && in_array($zm, $tablca) )
czy
if ( @in_array($zm, $tablca) )
0
2
Czemu się pytasz zamiast sprawdzić samemu, dzięki czemu nie musiałbyś nam wierzyć na słowo? Przykład pomiaru masz np. w manualu PHP online, w opisie funkcji microtime. Tylko umieść instrukcje w "odpowiednio dużej" pętli, żeby móc zmierzyć coś rozsądnego.
PS. Pamiętaj, że żadna z takich pojedynczych instrukcji nie będzie szybsza, jeśli nie wystąpi np. w większej pętli, często wywoływanej funkcji czy na witrynie z ekstremalnym ruchem. Przedwczesna optymalizacja to źródło wszelkiego zła. Czas potrzebny na zbędną optymalizację znacznie lepiej przeznaczyć na polepszenie jakości (struktury) kodu. Gdy kod będzie lepszej jakości, aplikacja powstanie dzięki temu szybciej i będzie miała mniej błędów, ew. będzie miała więcej/lepiej dopracowanych funkcji jeśli przeznaczysz na kodowanie tyle samo czasu. To bardziej wymierne rezultaty niż niemierzalne zyski w prędkości.
0
Odpowiedz teoretyczna.
Zalezy jaki masz procesor...
0
Zapewne i tak wykona się coś w stylu is_array na poziomie interpretera PHP (czyli kodu kompilowanego). Zakładając że instrukcje w kodzie interpretowanym są wolniejsze, to drugi warunek powinien być szybszy. Ogólnie jednak jestem stanowczo przeciw optymalizacji szczątkowej. Skupiając się na niej można położyć algorytmy które na prawdę mogą wygenerować kilkusekundowe obciążenie. Zresztą, wyobraź sobie że twoja kilkugodzinna praca przyspieszy skrypt o kilka milisekund, a na pewno zmniejszy czytelność kodu (w wielu przypadkach).
0
Jeżeli taka optymalizacja nie zmniejsza złożoności algorytmu, to daruj ją sobie. Prawdopodobnie nic nie zyskasz, szczególnie jeżeli jest to jednorazowe wywołanie.
0
Przeważnie niedoświadczeni adepci programowania łapią się na takie rady. "Żeby działało szybciej, używaj zawsze X, a nie Y!" Niektóre z tych rad są jakoś tam przydatne, np. żeby korzystać z preg_ zamiast ereg (ale tutaj akurat ereg jest już najzwyczajniej w świecie zdeprecjonowane). Fajnie by też było, gdyby kilka prostych porad odnośnie używania konstrukcji języka potrafiło faktycznie utrzymać wydajność na wysokim poziomie. W rzeczywistości tak jednak nie jest. Optymalizowanie aplikacji jest bardziej skomplikowane. Właściwy sposób postępowania, to -- po zobaczeniu niezadowalającej wydajności -- profilowanie kodu, namierzenie wąskich gardeł i sukcesywne eliminowanie (optymalizowanie) kolejnych z nich. Sprowadza się to zwykle do zmiany algorytmu, zastosowania wszelkiego rodzaju cache'owania, zminimalizowania liczby oraz złożoności zapytań do baz danych (optymalizacja samych baz to złożony temat). Niekiedy faktycznie pomaga proste ulepszenie jakiegoś kawałka kodu, ale tu chodzi o kod bardzo często wykonywany. Użycie np. echo zamiast print nie sprawi, że wolna aplikacja zacznie chodzić w znośnym tempie. Optymalizacja jednego (!) wąskiego gardła może to sprawić.