Tylko zeby przypadkiem ktos madry inaczej nie wpadl na pomysl usuwania komentarzy w celu 'tjuningowania' aplikacji.
Mikolaj Rydzewski
Ale to jest glupie tylko jesli zrobisz tak w swoich lokalnych zrodlach (i zmienisz nazwy zmiennych na jak najkrotsze ;). Ale jesli przeciagniesz czyms zrodla ktore slesz na produkcje to juz tak glupie nie bedzie a brak komentarzy w niczym nie przeszkadza.
Z powazaniem,
Ale to jest glupie tylko jesli zrobisz tak w swoich lokalnych zrodlach (i zmienisz nazwy zmiennych na jak najkrotsze ;). Ale jesli przeciagniesz czyms zrodla ktore slesz na produkcje to juz tak glupie nie bedzie a brak komentarzy w niczym nie przeszkadza.
PHPEncoder.pl
Mierzyl ktos ile us (mikro) mozna uzyskac taka operacja?
Jesli juz komus tak zalezy na wydajnosci (w sensie nie ze ma hopla, tylko faktycznie serwer jest obciazony) to instaluje akcelerator php ktory zlewa komentarze i dlugie nazwy, a nie bawi sie w kompresowanie kodu.
3. Rekord po rekordzie, czy wszystko naraz? 4. Jedno zapytanie vs. kilka zapytań.
Wszystko zalezy co chcesz osiagnac, jaki masz system, jakie problemy. Generalnie nalezy pisac czytelny kod, niezuzywajacy bez potrzeby masy zasobow. A skąd ja mam wiedzieć, na jakich systemach będzie odpalany skrypt? Hostingi są różne. Jedne lepsze, drugie gorsze. Działać ma wszędzie.
Czyli mam to rozumieć że sposób "linia po linii" jest lepszy? [nie zużywa niepotrzebnie tyle zasobów, skoro może mniej]
no przecież sam sobie odpowiedziałeś na szczęście są tu pomocne aAccceleratory, które prekompilują skrypty do bytekodu - pomijajac komentarze. Taki bytekod jest potem keszowany. Jednak to wymaga częstszego mielenia dyskiem przy dostępie do systemu plików i może lekko spowalniać skrypt przy mocno obciążonym dysku [dużo skryptów mieli nim naraz].
Nieprawda. Dane z dysku są czytane blokami. I dokładnie tyle samo operacji czytania bloków będą miały obie metody. 3. Rekord po rekordzie, czy wszystko naraz? []
O ile np. przy rekordzie piątym nie korzystasz z danych wcześniej wczytanego rekordu 2 to przesłanie wyniku zajmie dokładnie tyle samo czas/bajtow w obu przypadkach. A baza danych powinna keszować wyniki zapytania niezależnie od tego w jaki sposób je klient odbiera. Przykład: wyszukujemy tłumaczeń dla komunikatów GUI. Lepiej pobierać je na bieżąco, jakie akurat potrzeba, podając messageID i dostając tekst tłumaczenia? Czy może zbuforować to w jednym zapytaniu i dostać od razu całą listę komunikatów? W jednym skrypcie zrobili to nawet tak, że upchnęli wszystkie tłumaczenia jako jeden BLOB i za każdym razem zasysali z bazy wszystkie tłumaczenia i parsowali po stronie skryptu, by otrzymać tablicę tłumaczeń, z której później wybierali tylko te kilka potrzebnych dla danej strony ;P Przeraziło mnie to, bo wydaje mi się to kaszaniastym na maxa pomysłem, ale może jest w tym jakaś logika? :P
Całkiem rozsądne rozwiązanie. Chociaż jest to też pytanie czy przeparsowanie tego BLOBA po stronie PHP nie zajęłoby więcej czasu niż "naturalne" rozmieszczenie tłumaczeń w tabeli klucz=wartość. Ogólnie wczytanie sobie danych naraz do pamięci jest to tylko i wyłącznie problem ilości dostępnej pamięci. No to fajnie. Czy takie acceleratory są dostępne w PHP standardowo? Jak ta sprawa wygląda na różnych hostingach?
Powtarzam po kimś, nie sprawdzałem. Ale OK, dobrze wiedzieć.
Hmm.. w zasadzie to nie wiem skąd wziąłem ten pomysł z przesyłaniem danych z bazy jako całość, bo jak teraz przeczesuję dokumentację funkcji PHP do MySQL, to widzę, że wszystkie funkcje mysql_fetch_* pobierają po jednym rekordzie :| Jest wogóle możliwe przesłanie całej wynikowej tabeli za jednym zamachem?
A pytanie wzięło się stąd, że zastanawiałem się, czy jeśli skrypt będzie pobierał z bazy po jednym stringu tłumaczenia, w miarę potrzeby, to czy takie rozwiązanie ma sens, czy może lepiej zgromadzić je wszystkie jakoś w jedno zapytanie.
A możesz to jakoś uzasadnić? Bo mnie to się wydaje całkiem nierozsądne, wręcz potworne :| Jaki jest sens ciągnąć z bazy hektary tłumaczeń komunikatów dla każdej strony, jeśli na tej jednej stronie użyty zostanie ułamek procenta tych wszystkich stringów? :\
To też.
Której nigdy za wiele, a wręcz ciągle za mało ;J Zwłaszcza na darmowych/tanich hostingach, z których korzysta ogromna większość przeciętnych użytkowników.