Allegro.pl

Powiązane (3)

Pokaż: ustaw jako domyślne
pokaż obrazki

Komentarze (74)

  • Reklamy Google

  • Pawel28 +14  

    W programowaniu nie licza sie sekundy i kilobajty, w programowaniu liczy sie przejrzysty kod, bo taniej jest teraz dorzucic nowa maszyne niz zaplacic programiscie za kilka dni pracy. Jesli sie przyspiesza strone to rzadko na poziomie php. Juz lepiej zainstalowac jakies narzedzie, ktore bedzie przechowywac kod php w cache w skompilowanej formie np eaccelelator.

    tutaj kilka porad jak w realny sposob mozna przypieszyc strone.
    http://developer.yahoo.com/performance/rules.html
    i to so porady, ktore potrafia przyspieszyc wykonanie strony o rzad wielkosci, nie milisekundy :)

    pokaż komentarz
    Pawel28
  • _ts +11  

    Jeśli wogóle mówimy o wydajnym programowaniu, proponuje zrezygnować w całości z PHP ;-)
    Raz, że jest to mało skalowny i wolny (przy dużych obciążeniach/obliczeniach) język
    Dwa jest mało intuicyjny
    Trzy jest ciągle niedopracowanym językiem. Programowanie w nim niesie za sobą spore błędy wynikające z samego języka. Brak mu wspracia dla testów jednostkowych, widoczna i mocno denerwująca niekonsekwencja nazewnicta funkcji itp, itd..

    Jak to ktoś ładnie kiedyś powiedział program w PHP to tzw. spaghetti code co podtrzymuję.

    pokaż komentarz
    _ts
  • Tadzik +3  

    no i czego minusujecie _ts'a? Że niby kłamie? To może jakieś kontrargumenty, a nie minusy, głąby. Już kiedyś to napisałem, napiszę raz jeszcze:
    Gdy kończą się argumenty, zaczynają się minusy

    pokaż komentarz
    Tadzik
  • simo -9  

    Tadzik, myślę, że Twoja myśl przetrwa na pomnikach.

    pokaż komentarz
    simo
  • Tadzik +2  

    Wolałbym żeby przetrwała w mózgach niektórych wykopowiczów.

    pokaż komentarz
    Tadzik
  • simo -9  

    To była ironia, jeśli już o mózgach mowa.

    pokaż komentarz
    simo
  • EcceNux -2  

    @_ts trzeba było od razu pisać, że nie lubisz i nie programujesz w PHP - trochę łatwiej byłoby odczytywać Twoje porady ;-). Jeśli jako jedną z głównych wad wskazujesz nieintuicyjność (a zwykle prostota jest właśnie wskazywana jako główna zaleta PHP), to z resztą już trudno dyskutować ;-)

    pokaż komentarz
    EcceNux
  • _ts 0  

    EcceNux prostota to nie jest intuicyjność.

    pokaż komentarz
    _ts
  • IvanBarazniew +6  

    Cóż, artykuł porusza kwestie elementarne. Osoby, które na codzień zajmują się programowaniem zdają sobie z tego sprawę. Osoby, które się programowaniem zajmują, nazwijmy to "hobbystycznie", niekoniecznie, aczkolwiek nie powinny się one skupiać na optymalizacji.

    Przede wszystkim należy dbać o jakość kodu, przejrzystość rozwiązań. Najpierw piszemy aplikację porzadnie, sprawdzamy czy działa i jak szybko, a dopiero potem, jeżeli prędkość działania nas nie zadowala szukamy przyczyny. Po wykryciu przyczyny zastanawiamy się nad poprawieniem danego fragmentu, może zmianami w projekcie.

    Dlaczego o tym piszę. Poniewaz autor wspomniał o "zwykłej domowej stronie". W przypadku takich stron bardziej niż optymalizacja pomoże rozważne projektowanie. Trudno mi sobie wyobrazić "prostą domową stronę" wymagającą pętli o milionowych długościach. Dlatego proponował bym raczej zastanawianie się nie nad tym, czy użyć for czy while, ale raczej nad tym, którego algorytmu użyc do rozwiązania problemu. Oczywiście te "milisekundy" też się liczą, ale przyrost prędkości uzyskany usunięciem foreach nie zostanie pewnie zauważone przez użytkowników witryny, natomiast niepotrzebne użycie algorytmu o ponadlogartymicznej złożoności zostanie zauważone na pewno.

    Osobom, które chcą przyspieszać (a także ulepszyć) swoje skrypty zalecam poświęcanie czasu na naukę technik programistycznych, wzorców projektowych etc... w skrócie PROGRAMOWANIA. optymalizację należy zostawić na koniec.

    “The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet.” - Michael A. Jackson

    źródło: http://en.wikipedia.org/wiki/Optimization_(computer_science)

    pokaż komentarz
    IvanBarazniew
  • Pawel28 +2  

    Masz racje. Ponadto programowanie to nie jest znajomosc instrukcji jednego czy innego jezyka. Programista powinien dobierac odpowiedni jezyk do konkretnych potrzeb. Najwazniejsza rzecza jest znajomosc wzorcow projektowych i jesli ich nie rozumiemy to nie znaczenia w czym bedziemy pisac, nasz kod zawsze bedzie wygladal tak samo paskudnie. Na potrzeby stron interentowych w wiekszosci wystarczaja podstawowe wzorce jak MVC, Factory, Singleton, Decoratorion i Registry. Artykul skierowany do poczatkujacych raczej nie powinien sie skupiac nad tym czy lepiej uzyc count() czy sizeof(), artykul moim zdaniem jest wrecz szkodliwy...

    pokaż komentarz
    Pawel28
  • Alpha_Male +2  

    http://www.phpbench.com/
    kilka z tych przykładów omówione, m.in wyższość echo nad print

    pokaż komentarz
    Alpha_Male
  • madowatosc +10  

    Artykuł dobry, aczkolwiek pozwolę sobie skomentować co nieco i przyczepić się do nazewnictwa.

    6. Używaj time() zamiast date()
    Który szanujący się programista PHP używa date("U") do zwrócenia timestamp? Skoro funkcja date() pobiera wartość z time(), a na dodatek ma cały szereg możliwych argumentów, to oczywiste, że jest wolniejsza.

    7. Instrukcja intval() czy int?
    Podstawy programowania się kłaniają. Profesjonalnie nazywa się to rzutowaniem typów, a wykonuje się to następująco:
    $num = (int) '120';

    8. Kilka dobrych rad
    funkcja explode() działa odrobinę szybciej niż funkcja split()
    Nie ma sensu porównywania prędkości ww. funkcji, skoro split() korzysta z regex.

    funkcja echo jest nieco bardziej efektywne niż print
    Jest nieco bardziej efektywna, ponieważ nie jest funkcją, a tzw. konstrukcją językową.

    porównania wykonywane za pomocą operatora === działają wydajniej od tych wykonanych przy użyciu ==
    Operator === porównuje dane binarnie

    pokaż komentarz
    madowatosc
  • simo -1  

    O, i taki komentarz rozumiem. Konkrety, bez ładunku emocjonalnego. Plus.

    pokaż komentarz
    simo
  • _ts +6  

    Operator === porównuje dane binarnie
    Nie. Operator === to operator identyczności. Kontroluje on typ.

    Jest nieco bardziej efektywna, ponieważ nie jest funkcją, a tzw. konstrukcją językową.
    print także jest konstrukcją języka. Minimalna szybkość echo wynika z tego, że w przciwnieństwie do printa nie może zachowywać się jak "pseudo-funkcja", czyli np. nie zwraca wartości, przez co nie może być wykorzystywana w bardziej złożonych konstrukcjach języka co jest jej wadą.

    pokaż komentarz
    _ts
  • abc666 -2  

    @simo, a jak by nie było napisane że artykuł dobry to już by było źle?

    Poza tym jak ktoś nie wie o takich "pierdołach" tzn. że nie są mu one potrzebne.

    pokaż komentarz
    abc666
  • mark77 +3  

    Biedny łebh#%ting. Próbują się brać za "hardkor" jak umieją, a umieją niewiele. Takiego artykułu nie przyjęliby wam w redakcji "Komputer Świata". Więcej pożytku byłoby, gdybyście wylistowali wszystkie opcje funkcji printf() z C. Są w Wikipedii, można przepisać.

    Artykuł żałosny, więc zakop.

    Poza tym – bezczelny spam.

    Spam – dlatego:

    http://www.wykop.pl/ludzie/tyber16/linki

    A bezczelny – dlatego:

    http://www.wykop.pl/link/110476/webhostingowy-spamer-zwalcza-spam-na-wykopie

    pokaż komentarz
    mark77
  • M461K -3  

    to nie wina użytkownika , bo chciał dobrze , a to że podsunął mu to wykop i beznadziejny webhosting to już nie jego wina , i tak wykop dobije usera

    pokaż komentarz
    M461K
  • tyber16 -1  

    mark77 - konto założone do oczerniania określonego serwisu: http://www.wykop.pl/ludzie/mark77/linki/komentowane

    Żałosny, mały człowieczek, który poświęca swój czas nie na czytanie książek, spacer z rodziną, ale na oczernianie określonego serwisu. Pracujesz w konkurencji? To staraj się swoją pracą osiągnąć poziom Webhosting.pl. Potem będziesz się mógł wypowiedać.

    To nie jest spam - mogę sobie dokładać do Wykop.pl to, co uważam za wartościowe. Ty nic nie dokładasz, więc w zasadzie nawet nie jesteś częścią tej społeczności.

    Twój idiotyczny pomysł dotyczący "bezczelności" został oceniony przez wykopowiczów jednoznacznie. Szkoda, że tak się dzieje. Ten serwis nie zasługuje na to, by znosić tak przegranych wewnętrznie ludzi.

    pokaż komentarz
    tyber16
  • RobertG 0  

    @up
    Ten serwis nie zasługuje na to, by znosić tak przegranych wewnętrznie ludzi.
    Oj bardzo jadowita wypowiedź źle świadcząca o jej autorze. A co do webhosting'u lwia część jego notek które tu się pojawiają rzeczywiście ma niską jakoś merytoryczną (np. ten tekst vs uwagi do niego).

    pokaż komentarz
    RobertG
  • krytyk +7  

    Te porady są żałosne, brakuje jeszcze tylko sztuczki typu krótsze nazwy zmiennych.

    pokaż komentarz
    krytyk
  • dalka5000 -1  

    Nie wydaje mi się, by były żałosne. Za to Twój komentarz jest. Nie napisałeś nic merytorycznego. Takie komentarze piszą ludzie, którzy tylko chcą szkodzić.

    pokaż komentarz
    dalka5000
  • ula1980 -2  

    Widać, że nie masz o niczym pojęcia. Tak, jak napisałam poniżej, pewnie potrafisz zrobić licznik i może księgę gości w PHP. W prawdziwym programowaniu na serwery współdzielone chodzi o milisekundy - czy to Wam się podoba, czy nie.

    pokaż komentarz
    ula1980
  • simo 0  

    Wiesz, nie ma zdjęcia, nie ma wykopu... Są natomiast rady, jak można coś zrobić lepiej. A w Polsce przecież wszyscy są programistami doskonałymi, więc nie ma się co dziwić, że nie podoba im się ten wykop. To przecież my, Polacy, mamy siedem stacji orbitalnych, dwanaście podwodnych miast, kolonię na Księżycu i super armię androidów. Cóż można w tak wspaniałym społeczeństwie jeszcze poprawić, na co zwrócić uwagę... No na nic, nikomu.

    BTW: http://www.wykop.pl/link/110222/czemu-poziom-wykopu-tak-spada

    pokaż komentarz
    simo
  • _ts 0  

    ula1980 nie prawda. Co nas obchodzi czy program wykona się w 0,0001 czy 0,0002 sek. - nikt tego nie zauważy... Tak naprawdę chodzi o to aby np. w tym samym czasie 0,0002 wykonać 2x więcej tych samych operacji przy użyciu programowania rozproszonego/współbierznego/równoległego.

    pokaż komentarz
    _ts
  • EcceNux 0  

    @_ts problem w tym, że program w sieci może być wykonywany tysiące i więcej razy na raz na jednej maszynie, a to już robi różnice. Ktoś może np. klikać w linki otwierając je w nowych tabach, a jednocześnie 20 innych osób będzie robić to samo. Dodatkowo używana, wolniejsza operacja może być wykonywana w pętli po 1000 powtórzeń...

    Jak sobie to wszystko przemnożysz, to wyjdzie Ci całkiem nie mała liczba. Nie mała biorąc pod uwagę, to że współczesny użytkownik jest przyzwyczajony do szybkiej odpowiedzi, a nie tej rodem z Atari ;-).

    pokaż komentarz
    EcceNux
  • Cyberek +2  

    Ktoś może np. klikać w linki otwierając je w nowych tabach, a jednocześnie 20 innych osób będzie robić to samo.
    Wtedy aplikację projektuje się tak aby jedna osoba generowała wynik, a reszta go tylko oglądała.

    pokaż komentarz
    Cyberek
  • EcceNux 0  

    I oczywiście 20 wygenerowanych stron każda z pętlą po 1000 powtórzeń nie ma żadnego znaczenia... Szkoda dyskutować, bo widzę, że tu jakieś silne lobby anty PHPowe z założenia :-)).

    pokaż komentarz
    EcceNux
  • _ts -2  

    jakieś silne lobby anty PHPowe
    Nie, po prostu wypowiadają się tutaj ludzie, którzy oprócz bycia klepaczem kodu, chcą mieć przyjemność z programowania (co mnie bardzo cieszy ... chyba era pseudo-programistów w Polsce dobiega końca), a PHP takowej nie dostarcza, nie wspominając już o tym wszystkim czego w PHP zrobić się nie da.

    pokaż komentarz
    _ts
  • RobertG 0  

    @EcceNux
    Chyba nie zrozumiałeś odpowiedzi Cybereka, dla pierwszej osoby zostanie wygenerowana strona i zapisana gdzieś dla następnych userów (w bazie sql, w memcache etc). Gdy inni ludzie będą chcieli tą stronę zobaczyć dostaną kopię jej wygenerowanej zawartości z tego buforu (natychmiast, bez pętli z tysiącem powtórzeń). Można nie buforować całej strony, tylko część itp.. Średni czas generowania strony (długo czekający pierwszy i szybko obsługiwana reszta) przy dobrym doborze tego co się buforuje jest jest krótki i to jest realny zysk a nie opowieści jak w notce.

    pokaż komentarz
    RobertG
  • Pawel28 -1  

    _ts W php tez mozna, pisac duze aplikacje. Tylko nie robi sie tego w 'czystym' php tak jak nie uzywa sie do tego 'czystego' ruby, czy 'czystego' pythona. Tylko odpowiednio 'ruby on rails' i 'django'. Istnieje przeciez tyle dobrych frameworkow dla php, juz na dniach wychodzi symfony1.2, ktora jeszcze bardziej udoskonala testowanie aplikacji czy dzialanie formularzy. Uzywam symfony i nigdy nie zdarzylo mi sie napisac czegos co nazywasz spaghetti code. Jedyna wada dla mnie php dosyc uciazliwa jest to, ze funkcje w php nie zwracaja wyjatkow tylko wartosci. A to wszystko o tym, ze php jest nieskalowalne... :-) jest bardziej skalowalne niz JAVA. Zreszta nie spotkalem sie aby wielkim problemem w aplikacji Internetowej byl kod napisany w php, ruby czy innym jezyku. Jak sa problemy to zazwyczaj leza w tym jak zostala zaprojektowana baza danych i zapytania...

    pokaż komentarz
    Pawel28
  • Tadzik +1  

    To jak już narzekamy na php to dorzucę jeszcze brak możliwości przeładowywania funkcji. Krew zalewa momentami...

    pokaż komentarz
    Tadzik
  • Speedy -2  

    Przecież można rzucać wyjątkami w php.

    pokaż komentarz
    Speedy
  • _ts +3  

    Pawel28
    5 lat programowałem w PHP i uwierz mi, że nie ma w tym języku solidnie napisanego frameworka (brałem udział przy powstawaniu 2 framewroków i wiem jakie założenia i ograniczenia przyjmuje się już na starcie, a które wynikają z ograniczeń PHP).
    Osoba myśląca poważnie o programowaniu powinna wybrać inny język niż omawiany.

    jest bardziej skalowalne niz JAVA
    Tak... to powiedz mi jak się skaluje algorytmy w PHP i Javie, bo widzę, że nie bardzo masz pojęcie o tym co piszesz.

    Speedy
    Przecież można rzucać wyjątkami w php.
    Ale oprócz tego rzuca sobie raz notice raz fatal error, co jest jedną z największych porażek tego języka.

    Tadzik
    Rozumiem Cię, dlatego już od 2 lat nie używam PHP i jestem z tego faktu szczęśliwy :-)

    pokaż komentarz
    _ts
  • Tadzik +1  

    _ts a na co uciekłeś?

    pokaż komentarz
    Tadzik
  • _ts -1  

    Tadzik
    Python, a kolega w czym pisze?

    pokaż komentarz
    _ts
  • Pawel28 0  

    ts masz racje nic nie wiem na temat skalowalnosci algorytmow w JAVIE.... w realnym swiecie wszelkie madre dywagacje sprowadzaja sie do tego jak szybko mozna dostarczyc produkt do klienta, jak wiele uzytkownikow bedzie mozna obsluzyc na jednej maszynie i jak szybko bedzie bedzie mozna sobie poradzic ze zwiekszona ich iloscia i ile bedzie mnie kosztowac pozniejsze utrzymanie kodu.
    Rzadko aplikacje internetowe potrzebuja zawansowanych algorytmow. Jesli uzytkownikow jest zbyt wiele to kupujemy lepsze maszyne jesli to nie wystarcza... to sql wedruje na osobna maszyne sesje zapisujemy w bazie, dokladamy kilka maszyn i robimy najprostszy load balancing przy pomoca 'Round robin', statyczny content laduje na innej maszynie na np lighthttpd zamiast Apache. Nie wszystko sprowadza sie do jezyka jakiego uzywamy, tak naprawde duzo wiecej zalezy od servera (apache doskonale wspolpracuje z php) i jest tyle dodatkowych modulow.. jak wszystko nie wystarcza mozna dorzucic sobie jakis server proxy jak Squid. Zatrudnienie osobe znajaca sie na php jest takze tansze, niz zatrudnienie programisty Javy...i do cholery aplikacje napisane w JAVIE sa ciezkie... zapewniam Ciebie, ze jedna maszyna z Apache + php + symfony + modgzip + mod    expires + postgre/mysql+sphinx(dla szybkiej wyszukiwarki) uciagnie znacznie wiecej niz aplikacja w JAVIE. Iaplikacja w php jest tansza potem w utrzymaniu... Nie jestem jakims wielkim fanem php czy symfony, ale php potrafi na siebie zarobic i w 95% php + framework jest najlepszym mozliwym wyborem.

    pokaż komentarz
    Pawel28
  • Tadzik 0  

    _ts no problem w tym że w php : P
    Ale zaczynam się na nim zawodzić powoli, zastnawiam się nad perlem, a może ruby...
    Może przenieśmy te dywagacje na maila/jabbera/irca żeby tu nie śmiecić?

    pokaż komentarz
    Tadzik
  • Pawel28 0  

    Tadzik do przeladowywanie funkcji (metod w klasie ) w php5 istnieje funkcja __call nie jest to zbyt wygodne..., ale lepsze to niz nic. :-)

    pokaż komentarz
    Pawel28
  • _ts -1  

    Tadzik
    Skoro nie tylko dostrzegasz ułomność PHP, ale zaczyna Ci przeszkadzasz i co gorsze ograniczać to równie szybko dostrzeżesz to w Perlu. Dlatego proponowałby Ci poważnie się zastanowić na Ruby/Python.

    pokaż komentarz
    _ts
  • Tadzik +1  

    _ts a co jest ułomnego w perlu, czego jeszcze nie zauważyłem?

    pokaż komentarz
    Tadzik
  • szukaj_znajdziesz 0  

    Ciekawy tekst. Jedno z najważniejszych przesłań, które z niego płyną, brzmi: w programowaniu milisekundy są bardzo ważne ;).

    pokaż komentarz
    szukaj_znajdziesz
  • kompi 0  

    Może jeszcze zrobią testy na poziomie molekularnym z wywołaniami miliardy razy może jakieś miliardową część sekundy się zaoszczędzi. zasada jest prosta, pisac tak aby kodu nie dublować no i od tego jest Cache żeby nie generować niepotrzebnie tego samego.

    Druga sprawa: jak widze te zaj$$iste artykuły spamowe z webhosting to juz mnie skręca.

    pokaż komentarz
    kompi
  • dalka5000 -3  

    Spam? A widziałeś zakładkę Polecamy? Po co zaglądasz, jak Cię skręca? Co się dzieje w tym serwisie...

    pokaż komentarz
    dalka5000
  • kompi +1  

    polecane bo jest sponsorowane - proste.
    d%#!$ny artykuł napisany pod publiczkę - i nie sądze zeby byle jaki tekst od razu wrzucac na główną, tylko dlatego ze jest to webhosting.

    pokaż komentarz
    kompi
  • ula1980 -5  

    Ale dlaczego na główną "od razu"? To użytkownicy decydują, co jest na głównej. Jeśli użytkownicy głosują, to chyba to jest ok. A przecież na Polecane też trzeba głosować.

    Ważne: ci którzy piszą, że te tekst jest słaby, najprawdopodobniej nie mają pojęcia o programowaniu. A jeśli już jakieś, to chyba potrafią zrobić licznik i może księgę gości w PHP. W prawdziwym programowaniu na serwery współdzielone chodzi o milisekundy - czy to Wam się podoba, czy nie.

    pokaż komentarz
    ula1980
  • Cyberek 0  

    W artykule napisano o oszczędzaniu mikrosekund na prostych konstrukcjach programistycznych podczas gdy najwięcej czasu i tak zabiera dostęp do danych i to na tym powinien skupić się autor pisząc o optymalizacji.

    To co zostało przedstawione w artykule powinien wiedzieć każdy, kto zajrzał chociaż do dokumentacji. Poza tym przynajmniej połowa z przedstawionych sposobów powinna być znana każdemu programiście.

    Dlatego zakop :)

    pokaż komentarz
    Cyberek
  • simo -3  

    Czytaj dziecko to, co później komentujesz. Cytat z tekstu:

    "Pamiętajmy o tym, że często wąskim gardłem witryny jest baza danych, a zapytania do niej kierowane mogą nas „kosztować” ponad 90% czasu wykonywania skryptu."

    pokaż komentarz
    simo
  • Cyberek +1  

    Tato, a rozumiesz w ogóle co zacytowałeś i czego dotyczyła moja wypowiedź? Co z tego, że autor pisze o wąskim gardle jakim jest baza danych skoro nie poświęca jej w ogóle uwagi? Napisać, że coś działa wolno potrafi każdy głupi.

    Ja odniosłem się do porad, a tam nic o bazie danych nie napisali. Reszta tekstu mnie nie interesuje.

    pokaż komentarz
    Cyberek
  • anonim1133 0  

    Cóż, artykuł ujdzie, choć autor z PHP chyba nie za wiele ma wspólnego :P
    Ale ogólnie sam temat ciekawy i mam nadzieję, że zmusi chociaż parę osób do pogłębienia wiedzy w kierunku optymalizacji skryptów PHP, do czego ten artykuł to tak raczej średnio, w sumie nie za bardzo chyba możliwe, że się nie nadaję.

    pokaż komentarz
    anonim1133
  • miklosz -6  

    deja vu :)

    pokaż komentarz
    miklosz
  • _ts +35  

    Prymitywny artykuł, autor chyba nie ma wiele wspólnego z programowaniem:

    1. Preinkrementacja to co innego niż postinkrementacja! Więc nie można stosować zamiennie..
    2. "Używaj time() zamiast date()."
    Owszem, jeżeli chcemy jedynie czas w sekundach. Funckja date służy do formotawonia daty/czasu, więc jeżeli formatowalibyśmy surowy czas w sekundach zajęłoby to tyle samo czasu a może i dłużej.. (operacje matematyczne w PHP, a nie w rozszerzeniach C których używa date())
    3. "intval() vs int"
    intval() służy do konwersji liczb w różnuch systemach. Zwykłe int to rzutowanie, więc funkcje te nie służą do tego samego.
    4. "operatora === działają wydajniej od tych wykonanych przy użyciu =="
    Operator === i == to dwie różne rzeczy. Nie można stosować ich zamiennie w wielu wypadkach.
    5. "najwolniejszą ze wszystkich instrukcję for(){}"
    foreach() jest najwolniejszą instrukcją petli w PHP
    6. "przechowywać treści w plikach tekstowych. Stosowanie tych i podobnych „dobrych praktyk”"
    Plik nie zapewnia integralności danych, więc to na pewno nie jest dobra praktyka..
    7. "Co wybrać: strreplace() czy eregreplace()?"
    Warto wspomnieć o funkcji eregi_replace, która nie kontrolując CamelCase'ów działa szybciej.
    8. "Oszczędzaj pamięć"
    Przykład tam podany zadziała woniej niż gdybyśmy nie usuwali na końcu zmiennej z pamięci. Operacje takie się robi przy naprawdę dużych obiektach.. poza tym PHP ma garbage collection który usuwa wszystkie "śmieci"
    9. "Zredukuj liczbę wywołań funkcji"
    Funkcja sizeof() jest aliasem dla funkcji count(), więc teoretycznie jeśli już się tak bijecie o milisekundy lepiej jest używać jawnego wywołania na tablicy funkcji count()

    pokaż komentarz
    _ts
  • _ts +4  

    add1.

    "funkcja echo jest nieco bardziej efektywne niż print"
    Zarówno echo jak i print nie są funkcjami tylko konstrukcjami języka PHP, a to jest duża różnica.

    pokaż komentarz
    _ts
  • simo -8  

    Hmm, doceniam Twój wysiłek, ale większość Twoich uwag brzmi: nie zawsze można czegoś użyć. Zgadzam się, ale jak można, to dlaczego nie używać? Czy to daje od razu posmak prymitywności?

    Poza tym w tym tekście jest napisane to, o co tak strasznie tutaj się denerwujesz. Czy naprawdę byłeś w stanie przeczytać tylko tytuł i nagłówki?

    Cytat:
    "Prawdopodobnie nawet zastosowanie wszystkich wymienionych porad nie przyspieszy na tyle zwykłej, domowej strony, by stało się to zauważalne dla użytkownika. Jednak w przyszłości, gdy przyjdzie nam przygotowywać bardziej rozbudowane skrypty dla stron obsługujących dużą liczbę wywołań, ta wiedza może okazać się bardzo pomocna. Warto więc przyswoić ją sobie już teraz. Oczywiście zebrane w artykule wskazówki nie są uniwersalnym remedium na wszystkie bolączki niezoptymalizowanego kodu. Pamiętajmy o tym, że często wąskim gardłem witryny jest baza danych, a zapytania do niej kierowane mogą nas „kosztować” ponad 90% czasu wykonywania skryptu."

    pokaż komentarz
    simo
  • _ts +6  

    simo, czytam artykuły do końca potem je komentuje.
    Tytuł artykułu brzmi "8 sztuczek, za pomocą których przyspieszysz skrypty PHP", a nie "Powiemy Ci jak przyspieszyć skrypty, ale to i tak nie pomoże". Pojęcie optymalizacji jest jedno nieważne czy dla małych programów czy dużych. Czepiam się tego co autor napisał odnośnie samych konstrukcji języka i jego wiedzy na ten temat bo jest słaba.

    pokaż komentarz
    _ts
  • _ts +9  

    Nie ważne czy proste wskazówki, czy nie, czy jest ich kilka, czy więcej - w większości są po prostu błędne i napisane wysoce nieprofesjonalnie.

    A masz do mnie pretensje, że to ja nie czytam, tego co komentuje...

    pokaż komentarz
    _ts
  • _ts +5  

    Są błędne jeśli rozpatruje się je pod względem optymalizacji, co czyni autor artykułu.
    Jeśli nie znasz się na tym to łaskawie nie komentuj.

    pokaż komentarz
    _ts
  • voldenet +3  

    W php jest dużo funkcji, które mają różny czas wykonywania na Windowsie i Linuksie. Żeby to wszystko zoptymalizować, trzeba by testować każdą funkcję za pomocą microtime(). Jak ktoś szuka wydajności, to można zrobić instalkę na serwer, która generuje najwydajniejszy, zoptymalizowany kod. Z tym, że w wielu przypadkach to nie ma sensu...

    pokaż komentarz
    voldenet
  • kosiarz 0  

    _ts:
    Wykorzystując Twój sposób argumentacji ja skomentuję Twój punkt 7.

    "Funkcja eregi_replace i strreplace to dwie różne rzeczy. Nie można stosować ich zamiennie w wielu wypadkach."

    Co do punktu 8. To że PHP posiada GC nie zwalnia programisty z myślenia o zarządzaniu pamięcią. Dla GC nie jest obojętne czy ma zwolnić 10 obiektów czy 1000 oraz jak również maszynie nie jest obojętne czy obiekt zostanie usunięty z pamięci natychmiast czy za jakiś czas.

    To co poruszył autor w artykule to kropla w morzu, ktopla którą warto jednak znać.

    pokaż komentarz
    kosiarz
  • Cyberek +6  

    Simo, nie jesteś czasem humanistą? Wybacz ale te wszystkie "porady" są nic nie warte. Połowa dotyczy podstawowych podstaw, a druga połowa to porada w stylu: nie koś trawnika kombajnem.

    Jednak w przyszłości, gdy przyjdzie nam przygotowywać bardziej rozbudowane skrypty dla stron obsługujących dużą liczbę wywołań, ta wiedza może okazać się bardzo pomocna.
    Terefere srutututu. Przy większych serwisach pojawiają się problemy ala cachowanie, czy indeksowanie danych, a nie fakt, że strona generuje się kilka mikrosekund dłużej z powodu źle napisanej pętli.

    @kosiarz To co poruszył autor w artykule to kropla w morzu, ktopla którą warto jednak znać.
    To kropla, którą trzeba się znać. Przedstawione porady nie mają nic wspólnego z prawdziwym optymalizowaniem działania skryptu. Bo czy cenna jest porada nie wkładaj głowy do piekarnika? Dla dziecka może to będzie wartościowa wiedza, ale nie dla kogoś kto ma kilkanaście/dziesiąt lat na karku

    pokaż komentarz
    Cyberek
  • _ts +4  

    kosiarz
    Ja nie pisze artykułu i pozwoliłem sobie na małą uwagę dla zainteresowanych tematem.

    Co do GC to czytaj proszę co pisze... Napisałem, że warto usuwać duże niepotrzebne obiekty.. wywoływanie funkcji unset() dla każdej zmiennej nie jest oznaką "myślenia programisty" jak napisałeś.

    Cyberek
    True.

    pokaż komentarz
    _ts
  • kosiarz 0  

    _ts
    Artykułu nie napisałeś ale skomentowałeś a użyte przez ciebie niektóre argumenty są "prymitywne".

    1. Wciskasz że autor sugeruje iż zawsze zamiast operatora "==" powinno używać się "===" lub preinkrementacji zamiast postinkrementacji co jest nieprawdą. Zobacz jak łatwo można użyć takiej argumentacji również przeciwko Tobie (mój poprzedni komentarz).

    2. Pisząć "poza tym PHP ma garbage collection który usuwa wszystkie "śmieci"" sugerujesz że nie powinniśmy martwić się o pamięć co oczywiście jest błędne.

    3. "wywoływanie funkcji unset() dla każdej zmiennej nie jest oznaką "myślenia programisty" jak napisałeś". Bardzo proszę pokaż mi miejsce w którym ja lub autor artykułu to napisaliśmy?

    Na przyszłość nie naginaj czyjejś wypowiedzi żeby pasowała do Twojej racji/argumentacji lecz komentuj obiektywnie.

    pokaż komentarz
    kosiarz
  • kosiarz 0  

    Cyberek
    Zgadzam się z Tobą: "Dla dziecka może to będzie wartościowa wiedza, ale nie dla kogoś kto ma kilkanaście/dziesiąt lat na karku"

    Teraz cytując autora. "Warto także już na początku swojej programistycznej edukacji zapoznać się z kilkoma praktycznymi wskazówkami, które pozwolą uczynić projektowane w przyszłości rozwiązania bardziej wydajnymi.". Czy według Ciebie jest tu mowa o dziecku (początkującym programiście) czy o dorosłym (programiście doświadczonym)?

    pokaż komentarz
    kosiarz
  • Cyberek +3  

    Oczywiście, że mowa o początkującym programiście i do tego cały czas dążę. Wiedza zawarta w artykule moim skromnym zdaniem nie jest warta wykopywania, bo jej wartość merytoryczna jest znikoma.

    Wszystkie cenne informacje zawarte w poradach można poznać bardziej szczegółowo studiując dokumentację lub czytając dobry kurs, a od tego początkujący powinien zacząć. Przedstawiona wiedza jest tylko zlepkiem wybranych zagadnień.

    Ideą wykopu jest umieszczanie informacji unikalnych. Do kiczu jakim jest przedstawiony artykuł każdy może dotrzeć, zresztą niekoniecznie poprzez portal webhosting.pl

    pokaż komentarz
    Cyberek
  • kosiarz -2  

    Czytając Twoje komentarze odnoszące się do tego artykułu odnisłem wrażenie że oceniasz go jak by był napisany dla zaawansowanych programistów a tak nie jest. Obaj się zgadzamy że zagadnienia przedstawione w artykule powinna być znana każdemu programiście. Wynika stąd jednoznacznie że artykuł jest w pewnym sensie wartościowy.

    W swoich komentarzach nie oceniam czy artykuł jest dobry czy nie, wart wykopania czy nie. Do komentarza sprowokował mnie komentarz _ts'a, który był nie obiektywny i nie uczciwy.

    Swoją drogą również uważam że artykół nie jest wart wykopania gdyż zbyt powierzchownie porusza zagadnienie optymalizacji nawet jeśli odbiorcą ma być początkujący programista.

    pokaż komentarz
    kosiarz
  • _ts +2  

    kosiarz nie warto z Tobą dyskutować skoro nawet nie rozumiesz tego co napisałeś. Jeśli cytujesz mnie to zacytuj cały kontekst wypowiedzi, a nie wygodny dla Ciebie urywek
    "sugerujesz że nie powinniśmy martwić się o pamięć co oczywiście jest błędne."
    Dwa, czy trzy razy pisałem o pozbywaniu się z pamięci dużych, niewygodnych obiektów, ale jakoś przeczytać tego nie możesz. Jeśli masz jakieś podstawy programowania wiesz co się dzieje w momencie wywoływania funkcji i przekazywaniu jej argumentów... więc wyobraź sobie 1000 zmiennych na których zapisany jest jeden bajt danych, dla których za każdym razem wywołujesz 1000 razy funkcje odśmiecającą, a na końcu GC i tak jest uruchamiany - powodzenia.

    "Myślenie w programowaniu jest wskazane - wręcz pożądane".

    "_ts'a, który był (..) nie uczciwy."
    Zachowaj dla siebie takie uwagi, bardzo bym prosił.

    pokaż komentarz
    _ts
  • simo -2  

    Ja myślę, że kosiarz ma rację. _ts, nic nie pokazałeś, niczego nie udowodniłeś, sam zaproponowałeś coś bardzo dyskusyjnego. A jak Ci ktoś zwrócił uwagę, to twierdzisz, że nie warto z tym kimś dyskutować. Po co się w ogóle udzielasz, jeśli potem chcesz obrażać ludzi?

    pokaż komentarz
    simo
  • _ts +3  

    simo takie pytanie jeśli można.. jesteś programistą? Napisałeś tyle komentarzy, a nie przedstawiłeś żadnej konkretnej opini, ani własnych pomysłów na temat dyskutowanych rozwiązań.

    ps. Nie, nikogo nie obrażam, a na pewno nie mam takiego zamiaru.

    pokaż komentarz
    _ts
  • Wave +2  

    Jeszcze tylko słowo apropo stosowania "==" i "===" oraz pre i postintrementacji:
    skoro artykuł jest napisany dla początkujących programistów to nie możecie im wmawiać, że można używać tych rzeczy zamiennie!
    Poza pierwszym punktem nie ma tam niczego, o czym wartoby pamiętać.

    pokaż komentarz
    Wave
  • EcceNux -3  

    @_ts piszesz, że porady są głupie, bo nie zawsze da się je zastosować. Prosty przykład dlaczego Twoje rozumowanie jest błędne: "===" to oczywiście nie jest to samo co "==", ale niektórzy stosują dokładniejsze porównanie ("===") chociaż de facto tego nie potrzebują - np. używają, bo ktoś im powiedział, że tak jest bezpieczniej, co nie zawsze jest prawdą.

    Autor artykułu podał tylko statystyki i wskazał szybciej działające funkcje, które często można stosować zamiast. Sam autor zresztą podkreśla na końcu, że nie wszystko da się wymienić, a te rzeczy które przedstawił są jedynie dodatkowym kamyczkiem.

    A cachowanie to trochę inna bajka i oczywiście źle napisany skrypt z cachowaniem może być znacznie szybszy niż super zoptymalizowany skrypt bez cachowania. Co nie znaczy, że powinno się nabierać złe nawyki.

    To pisząc muszę jednak nie zgodzić się z jedną sugestią autora - żeby unikać konstrukcji typu:
    $string = 'abc';
    echo $string;
    Jeśli to jest w tym samym ciągu, to jest bez sensu. Ale jeśli wartość zmiennej jest ustawiana w ogólnym skrypcie, a wyświetlana w szablonie, to już jest zupełnie inna bajka. (vide http://pl.wikipedia.org/wiki/MVC )

    pokaż komentarz
    EcceNux
  • kedar 0  

    [komentarz usunięty]

    pokaż komentarz
    kedar
  • elceef 0  

    Nic nowego.

    pokaż komentarz
    elceef
pokaż 

Wykopali i zakopali (67 / 35)