Włączanie plików + autoloader, chętnie bym posłuchał ciekawych pomysłów Opcje

[Ociu]

2. Dodatkowy plik XML z klasami zewnętrznymi. W tym pliku będą zapisane w postaci XML dodatkowe klasy, które autoloader ma obsługiwać.

O to mi chodziło

Śpieszyłem się i zapomaniałem dopisać.

[chmolu]

IMO pliki XML w tym wypadku są niepotrzebne. Szybciej i wygodniej będzie to zrobić przy pomocy plików ini

[Nievinny]

XML to przeładowanie, a nam zależy na czasie, nie? Chociaż wszystko da się zrobić ;P

[matid]

XML to przeładowanie, a nam zależy na czasie, nie? Chociaż wszystko da się zrobić ;P

Przecież parsowanie pliku XML będzie się odbywać tylko w wypadku rekonstruowania mapy, co za często się dziać nie powinno, czyż nie? Zyskujemy natomiast na przejrzystości i strukturze pliku konfiguracyjnego.

[bigZbig]

@matid -> zauwazylem u Ciebie duze przywiazanie do technologi xml. Wiesz mnie sie zawsze wydawalo, ze ten jezyk zostal powolany do zycia po to, aby zapewnic przenosnosc danych pomiedzy roznymi platformami. Nie wiem czy w tym przypadku zapewnienie tej cechy jest pozadane. Uwazam ze próbujesz robic cos na sile utrudniajac sobie zywot.

[Nievinny]

@matid -> ale tą mapę musisz za każdym uruchomnienie skryptu załadować i to będzie się dziać często...

[matid]

@matid -> ale tą mapę musisz za każdym uruchomnienie skryptu załadować i to będzie się dziać często...

Przecież nie chodzi mi o trzymanie mapy w XMLu, bo jest to totalną pomyłką. Nie jestem aż tak przywiązany do XMLa żeby tracić na wydajności. Chodzi mi o trzymanie w pliku XML dodatkowych ścieżek do przeszukiwania, czyli parsowane będzie to tylko przy regenerowaniu mapy.

[Nievinny]

Czyli trzymasz tylko katalogi do parsowania? To nie ma sensu, ponieważ powinno się parsować wszystkie katalogi i uzyskać pełną mapę klas.

[Ociu]

Chodzi mi o trzymanie w pliku XML dodatkowych ścieżek do przeszukiwania, czyli parsowane będzie to tylko przy regenerowaniu mapy.

Przemyślałem sposób z XML i stwierdziłem, ze pomysł jest chybiony. Tak czy inaczej trzeba za każdym razem parsowac plik, traci się na tym cenny czas... A gdy tych dodatkowych ścieżek jest dużo ? wtedy czas wydłuża się do sek, a nie tysiącznych sekund.

[matid]

Przemyślałem sposób z XML i stwierdziłem, ze pomysł jest chybiony. Tak czy inaczej trzeba za każdym razem parsowac plik, traci się na tym cenny czas... A gdy tych dodatkowych ścieżek jest dużo ? wtedy czas wydłuża się do sek, a nie tysiącznych sekund.

Nie wiem jak sobie wyobrażasz wygenerowanie mapy w tysięczne sekund. W średniej wielkości projekcie (jeszcze bez czytania dodatkowych ścieżek, ok. 90 klas w różnych plikach) trwa to ok. 0,4 s. Czytanie z mapy to ok 0.0008s. Więc nie wiem jakbyś chciał kombinować, ale IMO niemożliwym jest generowanie mapy w tysięczne sekundy. Oczywiście mówię tutaj o mapie nie wymuszającej żadnego przystosowania nazwy pliku itp.

[Vengeance]

" trwa to ok. 0,4 s"

lol :] Mój kod (a ogolnie ten co podałem powyżej gdzieś), który rekurencyjnie schodzi katalogami w dół i zapisuje znalezione klasy już teraz wykonuje się czasem więcej niż 20 sekund :]
Oczywiście robione jest to tylko raz, przy pierwszym uruchomieniu.

[matid]

" trwa to ok. 0,4 s"

lol :] Mój kod (a ogolnie ten co podałem powyżej gdzieś), który rekurencyjnie schodzi katalogami w dół i zapisuje znalezione klasy już teraz wykonuje się czasem więcej niż 20 sekund :]
Oczywiście robione jest to tylko raz, przy pierwszym uruchomieniu.

Moja klasa autoloadera jest w znaczej części oparta na wypowiedziach i nawet fragmentach kodów z tego tematu, więc nie zdziwiłbym się, gdyby funkcja skanująca foldery (lub jej założenia) była już przez ciebie cytowana.

Prędkości w dostępie do plików mogą wynikać z różnego systemu operacyjnego (ja testuję lokalnie na linuksie, który ma świetny system buforowania dysków), procesora, pamięci, obciążenia, itp.
U mnie przeskanowanie ok 100 plików (ok. 1 MB) i stworzenie mapy zawierającej 90 klas trwa ok. 0,4s.

Oprócz tego mam napisany bardzo fajny system automatycznego regenerowania mapy, cachowania wyników, itp.

Ten post edytował matid 10.05.2005, 21:49:35

[Ociu]

Czepiasz się szczegółów, liczba była podana dla przykładu.

[Vengeance]

To nie było czepianie. Chodziło mi o sposób w jaki @matid osiągnął tak dobry jak dla mnie wynik. U mnie już powoli php robi time out przy generowaniu :] (WinXP, 950 MHz, 256mb RAM)

[matid]

Dla zainteresowanych - moja klasa Autoloader: http://matid.emmatrade.pl/files/Autoloader.class.phps

I jeszcze raz moje testy:
Sprzęt: Pentium 4 2,4 GHz, 1024 MB RAM, dysk twardy 7200 RPM (system plików: ReiserFS)
System: Ubuntu Linux 5.04 Hoary Hedgehog

Dane testowe:
Rozmiar: 913.6 KB
Liczba plików: 120
Liczba klas: 90

Czas generowania mapy po raz pierwszy po włączeniu komputera: 0.872271060944s
Czas generowania mapy po raz kolejny (część plików mogła być w buforze dysków): 0.427920103073

Ten post edytował matid 11.05.2005, 21:23:57

[hawk]

Skoro temat zrobił się popularny i każdy chce mieć swój autoloader oparty o mapy (co uważam za słuszne), to warto załatwić jedną prostą rzecz. Kompatybilność. Taka mapa to na tyle prosta struktura, że pewnie wszędzie wygląda tak samo:

[PHP] pobierz, plaintext 
<?php
$map=array(
  'nazwaklasy' => 'ścieżkadoklasy',
);
?>
[PHP] pobierz, plaintext 

Wtedy każdy może sobie generować mapę jak mu się podoba, szybciej lub wolniej. I każdą mapę można wrzucić do każdego autoloadera. Dobrze myślę?

Kompatybilność jest akurat bardzo ważna w przypadku autoloadera. Bo jeżeli napiszę jakąś bibliotekę, to wykorzystam swój pomysł. I ta biblioteka musi działać z biblioteką autorstwa kogoś innego, kto też oparł ją o swój autoloader. A autoloader może działać tylko jeden, więc jeżeli jeden do drugiego nie pasuje, to całość wychodzi do dupy.

[bigZbig]

@hawk -> Amen

[dr_bonzo]

...mam i ja.

Stworzylem swojego autoloadera:
- w konfigu podaje katalogi do rekursywnego przejrzenia
- podaje rozszerzenia plikow ktore maja byc tokenizowane

- mapa jest tworzona w std. formacie: nazwa_klasy => sciezka_do_pliku
- i zapisywana w formacie .ini (moze dorobie wybor ini | php)

I co najwazniejsze -- cachuje wyniki tokenizowania plikow (to nie to samo co 'mapa') -- tokenizowane sa tylko te co zostaly zmodyfikowane (okreslane przez filemtime()), co daje znaczna oszczednosc czasu. Zapisuje tablice:

[PHP] pobierz, plaintext 
<?php
 
array (
[ 'nazwa_pliku' ] ->
(
    [ 'classes' ] ->
    (
        [ 0 ] -> 'klasa_1';
        [ 1] - > itd...
    )
    [ 'modification_time' ] = 111123423423423; // czas modyfikacji
    { ['valid' ] = TRUE }
)
)
?>
[PHP] pobierz, plaintext 

Jak to wyglada w praktyce:
- wczytuje ww. cache
- przegladam katalogi i robie liste znajdujacych sie tam plikow
- loop po tych wszystkich plikach: porownuje czas modyfikacji pliku z czasem zapisanym w cache
- jesli plik zostal zmieniony to go tokenizuje i aktualizuje cache (+ ustawienie znacznika 'valid' w cache)
- jesli nie zostal zmodyfikowany to tylko ustawienie znacznika 'valid' w cache
- po przejrzeniu wszystkich plikow, usuwam te wpisy w cache, ktore nie maja znacznika 'valid', i usuwam znacznik 'valid' z tych, ktore go maja (tylko po to zeby go (znacznika) nie zapisac w cache)
- uzyskuje tablice z wpisami
nazwa_pliku --> klasy/interfejsy w min sie znajdujace + czas modyfikacji pliku
- zapisuje to cache
- na podstawie tego cache tworze mape

Wlasciwosci
- nowe pliki ktorych nie bylo w cache sa tokenizowane i dodawane do cache i mapy
- pliki ktore byly w cache a teraz nie istnieja (nie ma ich w podanych w configu katalogach) sa usuwane z cache i mapy
- pliki ktore byly w cache i nie zostaly zmienione nie sa tokenizowane (duuuza oszczednosc czasowa)
- pliki ktore byly w cache i zostaly zmodyfikowane sa ponowanie tokenizowane -> aktualizacja cache

Czasy wykonania:
6 klas / 5 plikow:
0.1137sec // bez cache
0.0041 sec // z cache

dodanie dodatkowych plikow i klas, w sumie
355 plikow / 138 klas
4.3358 sec // bez cache
0.1672 z cache// z cache

modyfikacja 3 z tych plikow (glowne pliki Smartyego -- 161kB) i utworznie mapy, z cache
0.7571 sec




Kodu jest sporo: > 470 linii, jak dokoncze to dam linka.
Pozostaje jeszcze fopisac __autoload()'a.

Ten post edytował dr_bonzo 26.05.2005, 15:16:32

[Vengeance]

Z twojego opisu wynika mi, że za każdym uruchomieniem klasy następuje rekurencyjne przejrzenie katalogów. Jeśli tak jest, to jest to tragiczne rozwiązanie :]

Po co te wszystkie "czasy edycji plikow" itp. Na co ci oszczednosc czasowa przy generowaniu mapy, skoro zalozeniem glownym jest ze robisz to tylko raz! Ewentualnie potem gdy cos zmieniasz w strukturze ponawiasz proces generowania.

Twoje "Jak to wyglada w praktyce" wg mnie powinno ograniczac sie tylko do:
1. przejrzenie rekurencyjne wskazanych katalogów
2. tokenizacja każdego pliku celem wyłapania zawartych w nim klas
3. zapisanie wszystkich powiązań klasa=>plik do .ini czy tam .php

A sam główny skrypt powinien tylko ów .ini lub .php wczytywać, zaś gdy go nie ma powinien uruchamiać generowanie ów pliku :]

Taka moja wersja

[dr_bonzo]

Z twojego opisu wynika mi, że za każdym uruchomieniem klasy następuje rekurencyjne przejrzenie katalogów. Jeśli tak jest, to jest to tragiczne rozwiązanie :]

Jesli mapa istnieje to ten skrypt nie jest uruchamiany.

Na co ci oszczednosc czasowa przy generowaniu mapy, skoro zalozeniem glownym jest ze robisz to tylko raz!

Przy rozbudowie aplikacji i sprawdzaniu poprawnosci jej dzialania nie bedzie mi sie chcialo czekac tych 5 czy 20 sekund na zobaczenie rezultatow.

"W praktyce" to robi + robi to szybciej jesli moze.