Włączanie plików + autoloader, chętnie bym posłuchał ciekawych pomysłów |
Tematy na forum Pro mogą zakładać jedynie moderatorzy. W otwartych tematach może pisać każdy, kto ma coś fachowego do powiedzenia. Wszystkie posty nie wnoszące nic do tematu będą natychmiast usuwane, a ich autorzy dostaną ostrzeżenie.
Jeśli uważasz, że jakiś temat jest warty dyskusji na tym forum, zgłoś go w temacie Propozycje.
Włączanie plików + autoloader, chętnie bym posłuchał ciekawych pomysłów |
5.08.2006, 16:44:16
Post
#141
|
|
Grupa: Zarejestrowani Postów: 358 Pomógł: 0 Dołączył: 3.07.2003 Skąd: Szczecin->niebuszewo->*(next to window) Ostrzeżenie: (0%) |
"bigZbig dla kaydego pakietu musisy kopiowac inicjaliyator cyz autoloade
-------------------- Jeśli życie to kara to nieźle nabroiłem ;-)
|
|
|
8.08.2006, 16:21:45
Post
#142
|
|
Grupa: Zarejestrowani Postów: 11 Pomógł: 0 Dołączył: 28.07.2006 Ostrzeżenie: (0%) |
Przepraszam, ale nie doczytałem tego wątku od deski do deski - limit czasu.
Kiedyś pisałem i niedawno też opisałem taką klasę autoloadera. Link. Wszelkie sugestie/komentarze wezmę chętnie pod uwagę =) -------------------- |
|
|
8.08.2006, 23:27:40
Post
#143
|
|
Grupa: Zarejestrowani Postów: 86 Pomógł: 0 Dołączył: 6.08.2004 Skąd: Warszawa Ostrzeżenie: (0%) |
Mógłby ktoś z was podsumować wszystkie te rozważania jakimś zgrabnym kodem autoloader'a? Taki najbardziej wydajny i uniwersalny?
@mtod: Fajna ta klasa, ale możnaby dla większej elastyczności dodać możliwość ładowania również nowych klas... -------------------- "Tylko myśl dojrzała i jasna daje się wypowiedzieć w słowach prostych" - prof. Witold Doroszewski
Warsztat: os: Windows XP, serwer: Apache 2.0.55, php: 5.1.4, baza danych: MySQL 4.1.7. |
|
|
9.08.2006, 11:57:53
Post
#144
|
|
Grupa: Zarejestrowani Postów: 11 Pomógł: 0 Dołączył: 28.07.2006 Ostrzeżenie: (0%) |
@lukir: nie rozumiem, jak to: "nowych"?
-------------------- |
|
|
12.08.2006, 10:24:01
Post
#145
|
|
Grupa: Zarejestrowani Postów: 86 Pomógł: 0 Dołączył: 6.08.2004 Skąd: Warszawa Ostrzeżenie: (0%) |
@mtod: na podanej przez Ciebie stronce jest napisane coś takiego:
Cytat Oczywiście cache należy stosować tylko w środowisku tzw. produkcyjnym, ponieważ w przeciwnym wypadku nowo dodane klasy będą poza zasięgiem autoloadera. ...,więc stąd moja propozycja, by rozszerzyć ten skrypt o możliwość automatycznego ładowania klas bez definiowania katalogu "produkcyjnego". Wtedy ten autoloader byłby wygodniejszy -------------------- "Tylko myśl dojrzała i jasna daje się wypowiedzieć w słowach prostych" - prof. Witold Doroszewski
Warsztat: os: Windows XP, serwer: Apache 2.0.55, php: 5.1.4, baza danych: MySQL 4.1.7. |
|
|
12.08.2006, 10:30:55
Post
#146
|
|
Grupa: Przyjaciele php.pl Postów: 698 Pomógł: 3 Dołączył: 28.03.2004 Skąd: Wrocław Ostrzeżenie: (0%) |
Wtedy ten autoloader straci na wydajności. Każdorazowe sprawdzanie całego drzewa katalogów jest czynnością zajmującą masę czasu. W moim systemie odświeżenie cache jest równe skasowaniu jednego pliku, więc nie wiem czy to takie męczące.
-------------------- |
|
|
12.08.2006, 11:09:43
Post
#147
|
|
Grupa: Zarejestrowani Postów: 358 Pomógł: 0 Dołączył: 3.07.2003 Skąd: Szczecin->niebuszewo->*(next to window) Ostrzeżenie: (0%) |
wracajac do wydajnosci __autoload() to wspomniane wczesniej 90% czasu wykonania to jaka bzdura. Ponizej przedstawiam Wam wynik szybkiego profilowania mojej przykladowej aplikacji programem PECL APD
Kod Total Elapsed Time = 0.27 Total System Time = 0.05 Total User Time = 0.06 Real User System secs/ cumm %Time (excl/cumm) (excl/cumm) (excl/cumm) Calls call s/call Memory Usage Name -------------------------------------------------------------------------------------- 28.6 0.01 0.01 0.02 0.02 0.02 0.02 242 0.0001 0.0001 0 is_array 14.3 0.06 0.08 0.02 0.03 0.00 0.00 9 0.0017 0.0035 0 require_once 14.3 0.00 0.08 0.02 0.06 0.00 0.00 5 0.0031 0.0125 0 include 14.3 0.01 0.01 0.00 0.00 0.02 0.02 4 0.0039 0.0039 0 defined 14.3 0.02 0.02 0.02 0.02 0.00 0.00 36 0.0004 0.0004 0 define 14.3 0.05 0.06 0.00 0.00 0.02 0.03 10 0.0016 0.0031 0 require 0.0 0.00 0.00 0.00 0.00 0.00 0.00 1 0.0000 0.0000 0 Forms_Register->_recursiveFilter 0.0 0.00 0.00 0.00 0.00 0.00 0.00 2 0.0000 0.0000 0 Forms_Register->_updateAttrArray 0.0 0.00 0.06 0.00 0.02 0.00 0.02 1 0.0000 0.0313 0 Forms_Register->registrationForm 0.0 0.00 0.00 0.00 0.00 0.00 0.00 2 0.0000 0.0000 0 Forms_Register->updateAttributes 0.0 0.00 0.04 0.00 0.00 0.00 0.02 11 0.0000 0.0014 0 Forms_Register->_loadElement 0.0 0.00 0.04 0.00 0.00 0.00 0.02 11 0.0000 0.0014 0 Forms_Register->addElement 0.0 0.00 0.00 0.00 0.00 0.00 0.00 11 0.0000 0.0000 0 Forms_Register->isTypeRegistered 0.0 0.00 0.00 0.00 0.00 0.00 0.00 4 0.0000 0.0000 0 Forms_Register->_parseAttributes 0.0 0.00 0.08 0.00 0.02 0.00 0.02 1 0.0000 0.0313 0 Registrations_RegistrationsOps->register 0.0 0.00 0.00 0.00 0.00 0.00 0.00 4 0.0000 0.0000 0 array_merge 0.0 0.00 0.00 0.00 0.00 0.00 0.00 2 0.0000 0.0000 0 View->setOutputData 0.0 0.00 0.02 0.00 0.00 0.00 0.00 2 0.0000 0.0000 0 Forms_Register->HTML_QuickForm 0.0 0.00 0.00 0.00 0.00 0.00 0.00 2 0.0000 0.0000 0 Forms_Register->HTML_Common 0.0 0.00 0.00 0.00 0.00 0.00 0.00 2 0.0000 0.0000 0 HTML_QuickForm_hidden->HTML_QuickForm_hidden Widac ze samej f-cji autolad nie ma w zestawieniu pozeraczy czasu, czas zabiera wykonanie includow a to czy sa wywolywane bezposrednio czy w autoladerze nie ma znaczneia jest tylko roznica w wygodzie bo uwazam lepiej jest napisac
niz
Ten post edytował squid 12.08.2006, 11:11:36 -------------------- Jeśli życie to kara to nieźle nabroiłem ;-)
|
|
|
18.08.2006, 22:52:45
Post
#148
|
|
Grupa: Zarejestrowani Postów: 132 Pomógł: 0 Dołączył: 24.09.2003 Skąd: Giżycko / Wrocław Ostrzeżenie: (0%) |
Ja, wykorzystując ujednolicone nazewnictwo klas, korzystam z autoloadera w taki sposób:
Żadne niepotrzebne klasy nie spowalniają mojego kodu - są wczytywane dopiero wtedy, gdy naprawdę są potrzebne. Świetnym przykładem mogą być klasy wyjątków. Możemy mieć 1000 różnych klas dziedziczących po Exception, które w żaden sposób nie spowalniają kodu, gdyż są ładowane dopiero po wyrzuceniu danego wyjątku. Powyższe, bardzo proste rozwiązanie, jest raczej przeznaczone do małych projektów z maksymalnie kilkunastoma klasami działającymi podczas jednego żądania ze względu na użycie wyrażeń regularnych. Dla większych projektów zalecane jest oczywiście mapowanie wszystkich klas opisane w tym temacie chyba wystarczająco obszernie -------------------- |
|
|
16.01.2007, 20:23:45
Post
#149
|
|
Grupa: Zarejestrowani Postów: 1 415 Pomógł: 117 Dołączył: 7.09.2005 Skąd: Warszawa Ostrzeżenie: (0%) |
Bardzo przydatne przy pisaniu autoloadera mogą być funkcje get_declared_classes" title="Zobacz w manualu php" target="_manual i get_declared_interfaces" title="Zobacz w manualu php" target="_manual. Niestety wiążą się z tym pewne problemy:
edit: Po zastanowieniu drugi problem, chyba nie jest jednak taki ważny. Skoro autoloader w zamierzeniu istnieje dla ładowania klas, nie wyobrażam sobie sytuacji w której ktoś miałby dołączać do deklaracji klasy jakieś instrukcje strukturalne. Chociaż, fakt-faktem jest to możliwe, a autoloader powinien być na to odporny. Co do wspomnianego limitu pamięci - testów nie robiłem i te standardowe 8M wbrew pozorom może pomieścić chyba dużo. A przecież klasy nie będą instancjonowane, z zasobów korzystać powinien tylko autoloader. Ten post edytował LBO 16.01.2007, 20:59:41 |
|
|
16.01.2007, 21:57:56
Post
#150
|
|
Grupa: Przyjaciele php.pl Postów: 5 724 Pomógł: 259 Dołączył: 13.04.2004 Skąd: N/A Ostrzeżenie: (0%) |
Cytat Skoro autoloader w zamierzeniu istnieje dla ładowania klas, nie wyobrażam sobie sytuacji w której ktoś miałby dołączać do deklaracji klasy jakieś instrukcje strukturalne. Chociaż, fakt-faktem jest to możliwe, a autoloader powinien być na to odporny. Taki exit to blad (w OOP), a bledy nalezy usuwac a nie hackowac (obchodzic) w autoloaderze. -------------------- Nie lubię jednorożców.
|
|
|
16.01.2007, 22:06:02
Post
#151
|
|
Grupa: Zarejestrowani Postów: 1 415 Pomógł: 117 Dołączył: 7.09.2005 Skąd: Warszawa Ostrzeżenie: (0%) |
Ten exit() to tylko przykład, nie mający zastosowania w prawdziwych aplikacjach. Zastąp to sobie czymkolwiek zechcesz. Chodzi o sam fakt, że model obiektowy php dopuszcza do takiego czegoś.
Ten post edytował LBO 16.01.2007, 22:06:31 |
|
|
17.01.2007, 15:13:32
Post
#152
|
|
Grupa: Zarejestrowani Postów: 2 262 Pomógł: 21 Dołączył: 3.05.2004 Skąd: Sopot, Krakow, W-wa Ostrzeżenie: (0%) |
Cytat Chodzi o sam fakt, że model obiektowy php dopuszcza do takiego czegoś. Tzn do czego ? Co ma ten exit do OOP ? -------------------- Javascript, Coffeescript, Node.js, Mongo, CouchDb, chmury, workery & inne bajery - zycie jest zbyt krotkie aby miec nudna prace :)
|
|
|
17.01.2007, 16:08:59
Post
#153
|
|
Grupa: Zarejestrowani Postów: 898 Pomógł: 48 Dołączył: 2.11.2005 Skąd: Poznań Ostrzeżenie: (0%) |
Ja napisałem sobie prosty autoloader - szczerze mówiąc jest tak prosty, że aż boli, ale nie wiem czego jeszcze mógłbym oczekiwać od tej klasy
Składają się na niego 2 klasy. ->Klasa główna korzysta z mapy plików (serializowana tablica klasa=>plik). Użyłem singletona dlatego mapa jest odczytywana tylko raz na początku skryptu. Jeśli plik znajduje się w mapie to wiadomo - odczyt jest banalnie prosty. Jeśli natomiast plik jest nowy/zmieniła się jego lokalizacja itp, to autoloader sam go wyszukuje. W tym celu autoloader ma scieżki, w których ma szukać oraz dodatkowo głębokość katalogów na jakiem ja szukać czyli np. $autoloader->addLocalization('sciezka', 5) oznacz ze ma szukac w katalogu 'sciezka' oraz rekurencyjnie do 5 katalogów niżej. Po pierwszym odnalezieniu pliku sciezka jest zapisywana do mapy i przy następnych wywołaniach przeszukiwania katalogów nie jest już potrzebne. ->klasa pomocnicza wykonuje operacje przeszukiwania katalogów itp. Oczywiście autoloader może mieć wskazanych kilka lokalizacji, w których ma szukać plików itd. Rozwiązania nigdy nie testowałem pod względem wydajności (piszę amatorsko więc nie zakładam, abym kiedyś popełił serwis o dużym obciążeniu), ale na logikę to rozwiązanie jest bardzo szybkie i nie powoduje zbędnych obciążeń. Jedno ograniczenie, to sposób wyszukiwania -> każda klasa musi być w osobnym pliku. To rozwiązania wydaje mi się najlepsze i na pewno jest bardzo wygodne. Ten post edytował athabus 17.01.2007, 16:09:30 |
|
|
17.01.2007, 16:52:03
Post
#154
|
|
Grupa: Zarejestrowani Postów: 740 Pomógł: 15 Dołączył: 23.08.2004 Skąd: Poznań Ostrzeżenie: (0%) |
Problem z mapą obrazków jest tylko taki, że za każdym razem trzeba ją całą załadować nawet jeśli żadnej nie użyjemy. Było już tutaj o tym, że można taką mapę podzielić na mniejsze zbiory, ale jest z tym troszkę zachodu. Lepszym rozwiązaniem jest sposób zastosowany w Zend Frameworku kiedy to nazwa klasy wskazuje na jej lokalizację w systemie. Wady tego podejścia są zasadniczo dwie. Po pierwsze dla każdej klasy trzeba wykonać parsowanie nazwy na ścieżkę, ale to pikuś, a po drugie jest to rozwiązanie mało elastyczne, które sprawdzi się tylko dla klas o odpowiedniej nazwie.
-------------------- bigZbig (Zbigniew Heintze) | blog.heintze.pl
|
|
|
17.01.2007, 17:18:00
Post
#155
|
|
Grupa: Zarejestrowani Postów: 898 Pomógł: 48 Dołączył: 2.11.2005 Skąd: Poznań Ostrzeżenie: (0%) |
W zf jest to bardzo fajnie rozwiązane - tu się zgodzę w 100%, ale bynajmniej nie z powodu wydajności, a z powodu przejżystości. Nie wiem jak u was, ale dla mnie to jest bardzo intuicyjne rozwiązanie jeśli chodzi o użytkowanie. Już sie nie zastanawiam czy tworzyć obiekt zend_db_table czy zend_table_db. Zamierzam w przyszłości przerobić swój zestaw klas na taką strukturę.
Ale wracając do mapy, to szczerze wątpię czy może ona stanowić realne obciążenie dla aplikacji (oczywiście zakładając, że nie składa się ona z tysięcy plików). Obecnie piszę mały projekcik w których korzystam właśnie z ZF + +/- 40 klas (przy includowaniu klas ZF korzystam z mechanizmu dostarczonego przez ZF i nie zapisuje scieżek do plików). Mapa zwiera zatem 40 scieżek. Myślę, że odczyt plus deserializacja to jest chwila. Pytanie co by było gdybym includował wszystkie klasy ZF poprzez mój mechanizm (czyli 383 pliki)... Na to pytanie nie potrafię jednak odpowiedzieć bo nie wiem jak kosztowna jest deserializacja. |
|
|
18.01.2007, 00:50:57
Post
#156
|
|
Grupa: Zarejestrowani Postów: 1 190 Pomógł: 27 Dołączył: 23.04.2005 Ostrzeżenie: (0%) |
Przeczytałem cały wątek (trochę czasu to zajęło) i mam kilka pytań dla bardziej wtajemniczonych:
1. Zastanawiam się po co korzystać z autoloadera? Tylko po to, żeby nie trzeba było ręcznie dołączać plików z klasami? Załóżmy, że mamy klasę A i klasę B. Klasa B dziedziczy po klasie A. Czy nie lepiej już w pliku z klasą B dodać require_once('klasa A')? Po co do tego wykorzystywać autoloader? 2. Rozumiem, że po wygenerowaniu mapy zapisujecie ją do pliku. Jak serializacja wpływa na wydajność? Czy warto jeszcze kodować jakimś algorytmem zserializowane wartości? 3. Dlaczego tak bardzo zależy Wam na uniwersalności. Przecież tworząc sobie framework czy coś innego, mamy pewien zarys jak to ma wyglądać. Jeśli będę korzystał ze swojego frameworka i jakiś innych bibliotek, to swoje klasy mogę ładować swoim autoloaderem a klasy innych bibliotek innym sposobem czyli najlepiej ręcznie (?) 4. Jaki macie sposób nazywania klas? Ja stosuję Nazwaprojektu_Nazwaklasy.class.php, np. Cube_Mysql.class.php Cube_Config.class.php Cube_ConfigException.class.php Cube_Exception.class.php 5. Czy ktoś z Was oprócz @squid'a testował jak ma się sprawa z wydajnością? Zastanawiam się czy warto go pisać, ale jeśli spróbuję to na pewno wykorzystam mapy i cache. -------------------- ”Godzina nauki w życiu nowoczesnego apostoła jest godziną modlitwy.”
(św. Josemaría Escrivá, Droga, 335) |
|
|
18.01.2007, 01:06:33
Post
#157
|
|
Grupa: Przyjaciele php.pl Postów: 5 724 Pomógł: 259 Dołączył: 13.04.2004 Skąd: N/A Ostrzeżenie: (0%) |
Cytat Czy warto jeszcze kodować jakimś algorytmem zserializowane wartości? Nie. Bo to nic ci nie da poza spowolnieniem dzialania przez wykonanie dodatkowych obliczen a rezultat bedzie taki sam. Cytat Jaki macie sposób nazywania klas? Ja stosuję Nazwaprojektu_Nazwaklasy.class.php, np. I jak piszesz nowy projekt i wykorzystujesz ponownie stare klasy to musisz zmieniac ich nazwy? Bez sensu. Cytat Rozumiem, że po wygenerowaniu mapy zapisujecie ją do pliku. Tak
-------------------- Nie lubię jednorożców.
|
|
|
18.01.2007, 01:16:20
Post
#158
|
|
Grupa: Zarejestrowani Postów: 1 190 Pomógł: 27 Dołączył: 23.04.2005 Ostrzeżenie: (0%) |
I jak piszesz nowy projekt i wykorzystujesz ponownie stare klasy to musisz zmieniac ich nazwy? Bez sensu. W sumie masz raje. Ale taki sposób przyjąłem pisząc sobie coś na styl frameworka. Zbór przydatnych klas, które będę wykorzystywał zawsze. Tak To było stwierdzenie nie pytanie :] Dalej zastanawiam się czy nie lepiej ładować ręcznie przez require_once().. -------------------- ”Godzina nauki w życiu nowoczesnego apostoła jest godziną modlitwy.”
(św. Josemaría Escrivá, Droga, 335) |
|
|
18.01.2007, 09:09:06
Post
#159
|
|
Grupa: Przyjaciele php.pl Postów: 5 724 Pomógł: 259 Dołączył: 13.04.2004 Skąd: N/A Ostrzeżenie: (0%) |
Cytat Dalej zastanawiam się czy nie lepiej ładować ręcznie przez require_once().. JEsli nie meczy cie ciagle pisanie: require( '/gdzie/ja/podzialem/ten/plik.php' ); to mozesz przy tym pozostac. -------------------- Nie lubię jednorożców.
|
|
|
18.01.2007, 16:52:08
Post
#160
|
|
Grupa: Zarejestrowani Postów: 472 Pomógł: 7 Dołączył: 7.12.2005 Skąd: Gliwice Ostrzeżenie: (0%) |
Ja nazywam klasy nazwa_klasy.class.php - to chyba najlepsze rozwiązanie. Klasy narzędziowe trzymam w jednym folderze i ładuję je autoloaderem, który tylko sprawdza czy dany plik istnieje (j.w.) - jeśli tak - ładuje go; nie - błąd. Co do ładowania klas z modułami etc. chyba zastanowię się nad metodą, którą opisał athabus - brzmi ona ciekawie.
-------------------- Silesian PHP User Group - www.spug.pl
Symfony2, OAuth2, budowanie API - masz pytania? Pisz! |
|
|
Wersja Lo-Fi | Aktualny czas: 18.04.2024 - 07:21 |