Programowanie, programowanie, programowanie… OK, znajomość języka, to podstawa, algorytmy są właściwie najważniejsze. Kiedyś – assembler, kilkanaście KB (kilobajtów) dostępnej pamięci, bezpośredni dostęp do procesora. Dzisiaj – C#, C/C++, Delphi, GB pamięci trwałej i swobodnej. Same procki dużo szybsze od tych „pierwotnych”. Niby wszystko jest w porządku, ale czy do końca?

Jak się rozwinęła osoba programisty?

Hmm… Dobre pytanie. Początkowo – komputery istniały jako zabawki (drogie zabawki) dla zapaleńców. Wtedy dużo prężniej funkcjonowała tzw. scena komputerowa. Dziś również ma się dobrze, ale nie o tym mowa. Mianowicie, wówczas dysponowano, jak już wspomniałem, stosunkowo skąpym sprzętem, na którym liczył się dosłownie każdy bajt. Co ciekawe, twory ówczesnych programistów niejednokrotnie wprawiały w zachwyt pomimo sprzętowej „biedy”. Obecnie mamy do dyspozycji masę bibliotek, DirectX, OpenGL tyle, że głowa mała.

Do czego zmierzam? Długi wstępniak, ale nie bez powodu. Do napisania tej notki zainspirował mnie wpis Sinxa. Kiedyś, przed umieszczeniem każdej instrukcji, zastanawiano się trzy razy, zanim dodano jakąś do kodu programu. Tak nawiasem, praktycznie wszystko było pisane w assemblerze pod stare, dobre x86 (mam tu na myśli 286, 386, 486, 486DX2 – ten ostatni posiadam) dopóki nie pojawiły się nowe procesory (mam tu na myśli Pentium, itp). Muszę tu wyrazić swoje uznanie ówczesnym twórcom za posiadaną wiedzę. Żadną rewelacją była sytuacja, w której trzynastoletni geecy znali na pamięć wszystkie rejestry procesorów i pokémonizm nie był im w głowach. Blebleble, znowu off-top. Co mamy dzisiaj?

Typowe podejście współczesnego programisty XXI wieku, to napisać, aby działało. Walnie jakąś dodatkową zmienną w kodzie, bo tak łatwiej; po co się męczyć, skoro jeszcze tyle pamięci pozostało. Jak to mawiają „grosz do grosza, a będzie kokosza” – zbierze się więcej takich zmiennych, a okaże się, że połowa zajmowanych zasobów, to te „ułatwiacze”. Jak to może się odbić na wydajności? Prosty przykład – XGL vs. Aero.

Pozornie może jest to złe porównanie, ale… Oba pakiety służą do „wypasienia” środowiska pracy. XGL – w Pingwinku, Aero – M$ Vista. Co mamy? O tym, jak XGL jest przebajerzony, to chyba tłumaczyć nie trzeba (a kto nie wie, niech sobie obejrzy filmiki na YouTube). Aero – ślimak, żółw czy co tam jeszcze nawet przy 1GB RAM-u. A XGL? Nawet przy 1/8 tego, przy takim samym akceleratorze chodzi w miarę przyzwoicie. O czym my w ogóle rozmawiamy? „Po co się męczyć? Może nikt nie zauważy?” Ot, takie dziwne, IDIOTYCZNE podejście.

Co mnie popchnęło do napisania tej notki? Doświadczenia? Podejście innych osób? Właściwie, to jedno i drugie (a przede wszystkim drugie). Miałem nieszczęście pracować z aplikacjami, których forma przerasta(ła) treść. Większość z nich zamieniłem na jakieś lżejsze odpowiedniki. Ale drugi aspekt – podejście… W ciągu paru dni odbyłem kilka interesujących rozmów czy też dyskusji.

Najbardziej trzeba się „przyczepić” do początkujących, nie za sam fakt, iż są „zieloni”. Każdy przecież nim był albo jeszcze jest. Z racji zajęcia, najwięcej czasu poświęcam PHP, itp. Otóż, Rozmawiam z osobami, które dopiero wkraczają w Świat Słonia (nie, nie aluzja do szybkości, tylko do logo :D). Te osoby zaczynają zazwyczaj (zawsze) od kursów opublikowanych w Sieci. Tylko jest jeden, mały problem: manual – „coś takiego jest”. W podręczniku PHP, oprócz samych objaśnień działania funkcji, można się dosyć często natknąć na uwagi redaktorów dotyczące wydajności. Praktycznie zawsze jest wskazana wydajniejsza „alternatywa”. Następnie, komentarze pod właściwym tekstem (dostępne tylko w bardziej rozbudowanej, angielskiej wersji podręcznika w formacie CHM lub w manualu on-line). Niby nic, ale często są tam bardzo wartościowe wskazówki. Do czego zmierzam – ludzi cechuje lenistwo, przede wszystkim – lenistwo i jeszcze raz lenistwo, które objawia się np. takimi kwiatkami:

$query = "select * from dodaj";
$result = mysql_query($query);
$num_results = mysql_num_rows($result);

";
for ($i=0; $i <$num_results; $i++) { $row = mysql_fetch_array($result); print stripslashes($row["ID"]); print ". "; $zmienna = stripslashes($row["ID"]); ?>


";
}

Sprawdzamy stronę podręcznika dla funkcji print. Co znajdujemy w komentarzach? Ano, ktoś pofatygował się przetestować wydajność poszczególnych funkcji wykonujących w sumie to samo (w uogólnieniu!).

Wychodzenie z bloku PHP dla wypisania tylko trzech znaków, dwukrotne przetwarzanie tej samej wartości, print zamiast echo, wyciąganie z bazy wszystkich pól zamiast tylko dwóch potrzebnych…

Jak by to mogło wyglądać?

$query = 'select `ID`, `nazwa` from dodaj';
$result = mysql_query($query);
$num_results = mysql_num_rows($result);

';
while($row = mysql_fetch_array($result)){
echo $row['ID'].'. '.$row['nazwa'].'
';
}

Widać różnicę? A co wystarczyło? Przede wszystkim, lektura manuala…

Zerkam czasem na Polskie Forum PHP (poznasz kto jest kim po awatarze :)). Kilka dni temu powstał wątek, którego autor prosi o wytłumaczenie pewnego kawałka kodu. Gadka-szmatka, wskazanie odpowiednich stron w manualu. Parę postów, temat zszedł na wydajność i pewnym momencie, uświadamiania owieczka napisała:

Dzieki za uwage, a nauczył Mnie tak kurs php + mysql

… – To jest mój komentarz. Przepraszam, ale jeśli ktoś pisze np. pracę dyplomową, to opiera się wyłącznie na jednym źródle (choć mogę się mylić ;P)? A głowa na karku, to co? Napiszą „skocz w ogień” i co wtedy?

Ostatnio zapanowała moda na pisanie o czymś, o czym się nie ma zielonego pojęcia. Kolega Michno rezyduje na forum webtips.pl. Pewnego razu pojawił się temat o HTML-u. Okazało się, że gość robi kurs, a nie ma pojęcia o wręcz podstawowych rzeczach. Dzięki takim przykładom zaczynam się coraz bardziej utwierdzać w przekonaniu, że trzeba wprowadzić cenzurę w Internecie (mam na myśli moderowanie treści pod względem merytorycznym).

Podejrzewam, że wspomniany przez autora tematu na PFP kurs PHP był podobnego pokroju. To, że internet zapewnia POZORNĄ anonimowość nie oznacza, że można od razu pisać bzdury.

Odłamem jest również zjawisko, które można opisać mniej więcej tak: „nie znam się na samochodach, ale umiem robić kotlety”:
z webtips.pl (kontekst znajomości HTML-a):

Sugeruje dowiedzieć się, że dobrze o tym wiem i znam dobrze php.

z forum.php.pl

Może doświadczenie w PHP + MySQL mam niewielkie to fakt, beginner jestem w tych dziedzinach.
W każdym razie na serwerach znam się dość dobrze, jestem posiadaczem sieci osiedlowej 100 osób i troche znam życie TCP/IP

Ale co ma, w tym wypadku, piernik do wiatraka?

Powracając do głównego tematu:

Tak, ale ja mialem na mysli, ze czas generowania strony, nie ma wiekszego znaczenia przy czasie przesyłu danych.

To tak jak masa elektronu do neutronu, ma tak niewielka, ze sie nawet nie liczy.

Siedzimy Sobie przed kompem klikamy na jakąś strone w php. Ile czekamy?

czas_oczekiwania = x + y + z

x – czas przesyłu zapytania od nas do serwera
y – czas generowania strony (zapytania do bazy etc.)
z – czas przesyłu odpowiedzi od serwera do nas

Gdzie „y” to wartości rzędu setnych i tysiącznych sekundy, a „x” i „z” to juz zalezy od tego przez ile routerow przechodzi połączenie i jaką mamy prędkość tego połączenia.

Mike_mech (spokojnie mogę powiedzieć, że ekspert w dziedzinie projektowania aplikacji WWW w PHP) skwitował:

Najprościej mówiąc: bardzo sie mylisz, dlatego, że bagatelizujesz bardzo wiele czynników. Bądź po prostu ich nie znasz

Święte słowa, trzeba w ramki oprawić. Ale, szczerze mówiąc, nie rozumiem podejścia:

Kurs, nie zmienie go, bo jest to kurs praktyczny i sa dosc ciekawe przykłady. Nawyki złe i dobre zawsze mozna zmienic, wiec jakos dam rade.

Tylko po co dwa razy tracić czas i walczyć później z samym (samą) sobą?… Wtedy, nie wszystkie nawyki uda się zmienić…

Kolejny cytat:

Czas y jest zależny od kodu, jak i od maszyny fizycznej (serwera), która parsuje dany kod. Jeżeli y byłby rzędu 5 sec, to nie znak, że kod źle napisany (nie zawsze), tylko, że trzeba serwer lepszy kupić i tyle.

Najgorsze jest to, że takie podejście reprezentują nie tylko początkujący. Tych bardziej doświadczonych również stać na tego typu teksty. Rozbraja mnie podejście: „Po co się męczyć, skoro coś działa? Nie będę marnował(a) na to czasu.” Albo: „jak będzie wolno chodzić, to się zmieni/ulepszy serwer…” Fakt, projekty, itp. wykonuje się na czas. Ale czy nie można od początku robić jak trzeba? Owszem, wymaga to większego samozaparcia, ale jest możliwe. Powraca tu sytuacja tzw. kartki papieru: Co trzeba zrobić? Co mamy zrobić? Jakie jest najoptymalniejniesze rozwiązanie. Dlaczego kartka papieru? Kiedyś padło powiedzenie:

Kartka papieru, to wynalazek przestarzały – nic się samo nie policzy, nie można wyciąć ani wkleić. Ale ma jedną, wielką zaletę: posiada nieograniczone możliwości formatowania.

Komputer, w tym wypadku, tylko pogorszy sprawę. Rozrysować, wybadać, nie bać się pytać o rady innych. Nawet najlepsi się mylą. Na pewno nie poruszyłem wszystkich kwestii problemu. Ale mam nadzieje, iż uświadomiłem choćby 1 (słownie: jednej) osobie dlaczego tak, a nie inaczej…