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ś.

Tzn do czego ? Co ma ten exit do OOP ?

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.

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.

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.

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.

Nie. Bo to nic ci nie da poza spowolnieniem dzialania przez wykonanie dodatkowych obliczen a rezultat bedzie taki sam.


I jak piszesz nowy projekt i wykorzystujesz ponownie stare klasy to musisz zmieniac ich nazwy? Bez sensu.

Tak

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.

To było stwierdzenie nie pytanie :]

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.

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.

Witam.
Ja wykombinowałem coś takiego:
Klasa:

[PHP] pobierz, plaintext 
<?php
class ClassLoader {
 
	/**
	 * Class file name sufix
	 *
	 * @var string
	 */
	private $file_sufix = '.class.php';
 
	/**
	 * Class map cache file name
	 *
	 * @var string
	 */
	private $cache_file_name = 'class_map_cache.ini.php';
 
	/**
	 * Path to cache file
	 *
	 * @var string
	 */
	private $cache_file_path = CONFIG_PATH;
 
	/**
	 * Root path of the project
	 *
	 * @var string
	 */
	private $base_path = BASE_PATH;
 
	/**
	 * Path to class files & packages
	 *
	 * @var string
	 */
	private $class_path = CLASS_PATH;
 
	/**
	 * All files paths from readed dir
	 *
	 * @var array
	 */
	private $readed_dir;
 
	/**
	 * Class map content
	 *
	 * @var array
	 */
	private $class_map;
 
	/**
	 * ClassLoader class instance
	 * 
	 * @var ClassLoader
	 */
	private static $instance;
 
 
 
 
	/**
	 * Constructor
	 * 
	 * @access private
	 */
	private function __construct() {
		$this->getClassMap();
	}
 
	/**
	 * Gets singleton instance of ClassLoader class
	 *
	 * @return ClassLoader
	 * @access public
	 */
	public static function getInstance() {
		if (is_null(self::$instance)) {
			self::$instance = new self;
		}//end if
		return self::$instance;
	}
 
 
 
 
	/**
	 * Loads single class or all class package 
	 *
	 * @param string $class_name - name of class to load
	 * @access public
	 */
	public function load($class_name) {
		$class_name = str_replace('.', DIRECTORY_SEPARATOR, $class_name);
		if (strstr($class_name, '*')) {	// load all class package
			$package_path = str_replace('*','', $class_name);
			$classes_arr = $this->getDirContents($this->class_path . $package_path);
			$this->loadClass($classes_arr);
		}else{	// load single class
			$path = $this->class_path . $class_name . $this->file_sufix;
			$this->loadClass(array($class_name => $path));
		}//end if
	}
 
 
	/**
	 * Serches for requested class in entire project and loads automaticly if found
	 *
	 * @param string $class_name
	 * @access public
	 */
	public function autoLoad($class_name) {
		if (array_key_exists($class_name, $this->class_map) && file_exists($this->class_map[$class_name])) {
			require_once($this->class_map[$class_name]);
		}else{
			$this->generateClassMap();
			if (array_key_exists($class_name, $this->class_map) && file_exists($this->class_map[$class_name])) {
				require_once($this->class_map[$class_name]);
			}else{
				throw new Exception('Class AutoLoad failed, file '. $class_name . $this->file_sufix .' not found');
			}//end if
		}//end if
	}
 
 
	/**
	 * Loads class
	 *
	 * @param array $path
	 * @access private
	 */
	private function loadClass($path) {
		foreach($path as $key => $val) {
			if (file_exists($val)) {
				require_once($val);
			}else{
				throw new Exception('Load class failed, file '. $key . $this->file_sufix .' not found');
			}//end if
		}//end foreach
	}
 
 
	/**
	 * Reads class map from cache
	 *
	 * @access private
	 */
	private function getClassMap() {
		if (file_exists($this->cache_file_path . $this->cache_file_name)) {
			$this->class_map = parse_ini_file($this->cache_file_path . $this->cache_file_name);
		}else{
			if (!is_dir($this->cache_file_path)) mkdir($this->cache_file_path);
		}//end if
		if (empty($this->class_map)) $this->generateClassMap();
	}
 
 
	/**
	 * Generates new class map
	 *
	 * @access private
	 */
	private function generateClassMap() {
		$this->getDirContents($this->base_path);
		$this->class_map = $this->readed_dir;
		$this->saveClassMap();
	}
 
 
 
	/**
	 * Saves class map into a cache file
	 *
	 * @access private
	 */
	private function saveClassMap() {
		$str = ";<?php die('Configuration file, all data confidential'); ?>rnrn";
		foreach($this->class_map as $key => $val) {
			$str .= $key .' = '. $val . "rn";
		}//end foreach
		file_put_contents($this->cache_file_path . $this->cache_file_name, $str);
	}
 
 
	/**
	 * Gets specified directory contents recursively
	 *
	 * @param string $path
	 * @return array
	 * @access private
	 */
	private function getDirContents($path) {
		$this->readed_dir = array();
		$this->readDir($path);
		return $this->readed_dir;
	}
 
 
	/**
	 * Reads specified directory & if file name contains "class" substring adds path to $readed_dir array
	 *
	 * @param string $path
	 * @access private
	 */
	private function readDir($path) {
		if ($handle = opendir($path)) {
			while (($file = readdir($handle)) !== false) { 
				if (is_file($path . $file) && strstr($file, 'class') && !strstr($file, 'ClassLoader')) {
					$this->readed_dir[str_replace('.class.php', '', $file)] = $path . $file;
				}else if (is_dir($path . $file) && $file != '.' && $file != '..') {
					$this->readDir($path . $file . DIRECTORY_SEPARATOR);
				}//end if
			}//end while
			closedir($handle);
		}//end if
	}
 
}
 
 
 
/**
 * Class auto loader
 * 
 * @param string $class_name
 */
function __autoload($class_name) {
	$cloader = ClassLoader::getInstance();
	$cloader->autoLoad($class_name);
}
 
?>
[PHP] pobierz, plaintext 

config.php

[PHP] pobierz, plaintext 
<?php
/** Base path */
define('BASE_PATH', dirname(__FILE__) .'/');
/** Path to config files */
define('CONFIG_PATH', BASE_PATH . 'config/');
/** Path to class and interface files */
define('CLASS_PATH', BASE_PATH .'classes/');
?>
[PHP] pobierz, plaintext 

możliwość ładowania klas trochę IMO przyjemniej niż require_once i klepanie ścieżki
możliwość ładowania paczek klas
autoloader
mapa klas keszowana w pliku ini
gdy w keszu nie ma żądanej klasy jest odświeżany i ponowna próba załadowania klasy, jeśli brak - wyjątek

Przykładowe wywołanie:

[PHP] pobierz, plaintext 
<?php
require_once('config.php');
require_once(CLASS_PATH .'core/ClassLoader.class.php');
$c_loader = ClassLoader::getInstance();
$c_loader->load('core.JakasKlasa'); // ładuje wskazaną klasę w "paczce" core
$c_loader->load('core.*'); // ładuje całą "paczkę" core
$c_loader->autoLoad('Smarty'); // odszukuje w całym projekcie wskazanej klasy i ładuje jeśli znajdzie
?>
[PHP] pobierz, plaintext 

metoda "load" ładduje klasy tylko ze zdefiniowanego w klasie ClassLoader katalogu i podżędnych
metoda "autoLoad" odszukuje żądaną klasę w całym projekcie

Ciekawi mnie co mądrzejsi będą mieli do powiedzenia.
Jeśli będzie się to do czegoś nadawało to można wrzucić do gotowych skryptów.

PS
Różnic przy tej klasie w porównaniu do ręcznego klepania require nie zauważyłem (ładowanie ok 20 klas).
//edit, no dobra tu troche przesadziłem, różnica jest
PS2
Jedyne wymaganie to nazwa pliku klasy powinna kończyć się ".class.php"

I co, nikt nic ?
Czyżby to było tak beznadziejne że nie warto się wypowiadać ?

Bardzo ładna klasa, mi się podoba - jakbym stosował autoload to bym mógł ją spokojnie użyć.

Paser ini jest szybszy od serialize to też dodatkowy plus.

[PHP] pobierz, plaintext 
<?php
if (strstr($class_name, '*')) {	// load all class package
			$package_path = str_replace('*','', $class_name);
			$classes_arr = $this->getDirContents($this->class_path . $package_path);
?>
[PHP] pobierz, plaintext 

Czy w tym momencie nie było by lepiej użyć glob" title="Zobacz w manualu php" target="_manual() ?

Dzięki bardzo.

Gdybym ładował pliki tylko ze wskazanego folderu to napewno tak, natomiast moim zamiarem było załadowanie plików/klas ze wskazanego folderu i wszystkich w nim zagłębionych.

Hmm... Klasa ciekawa i sporo wyjaśnia Dzięki. ale ja mam odmienny problem. Jak się ma sprawa z autoloadem interfejsów? Jak nie ma jest uruchamiana funkcja autoload?

Ja nazywam swoje klasy zgodnie z konwencją przyjętą w Zend Frameworku. Oczywiście zamiast prefixu Zend daje swój. DjKermit - narzucając obowiązek nadawania klasom sufixu class.php ograniczasz swojego autoloadera jedynie do klas swojego autorstwa i klas, które zawarte są w plikach o nazwach stosujących tę konwencję. Gdzieś na początku tego tematu jest przykład bardziej uniwersalnego skanera.

Dlaczego serializujecie swoje mapy albo tez parsujecie do postaci pliku ini? Nie lepiej zapisywać je od razu jako tablicę i na dzień dobry tę tablicę includować?

bigZbig: Podobno szybsze jest Ale zastanowię się nad tabliczką .

No tak, ale nie piszę publicznego FW tylko pewien systemik, którego częścią jest ten loader, i nawet jeśli korzystam z cudzych klas to przerabiam je do swoich konwencji.



IMO gryzie się to z ideą OOP bo inkludująć tablicę masz ją w globalu a nie w klasie czy metodzie klasy, pozatym podobno ini jest najszybsze, no i jakoś tak czytelniej.

Jak init może być szybsze od tablicy skoro parsując plik init zmieniasz go właśnie w tablicę. Tablicę możesz wczytywać do klasy poprzez pobranie zawartości pliku, a nie poprzez includa. Możesz też wygenerować mapę w postaci instancji klasy implementującego interfejs ArrayAccess i wtedy includujesz gotowy obiekt. Myślę, że powinno zadziałać choć nie testowałem.

hmmm, parsowanie to parsowanie... i "na oko" parsowanie kodu php jest bardziej czasochłonne od pliku ini, który jest prostszy

Ja zapisuje zserializowaną tablicę i działa sprawnie.

O autoloadzie oraz przykładowa klasa generująca mapę opublikowałem post na moim blogu: http://strzalek.net/blog/8/autoload-automa...-ladowanie-klas

Mnie zastanawia ile samo odwolanie sie do funkcji autoload zajmuje czasu, Bo to jak zbudujesz ta funkcje tak bedzie ona sprawna.
Jesli autoload ma szukac po wszystkich katalogach to tak, bedzie to wolne. Ale jesli podzielic pliki na grupy, uzyc odpowiednich schematow w budowaniu nazw klas to powinno byc to sprawne.
Chyba ciekawszym sposobem to kozystanie z magazynu obiektow polaczonego z autoloaderem. Odwolujesz sie do magazynu po obiekt jakiegos modelu, ktory ma miec zawsze jedna instancje aby powiedzmy nie powielac polaczen z baza danych. Magazyn sprawdza czy istnieje juz taka instancja, jesli nie sprawsza czy istnieje taka klasa, jesli nie szuka w odpowiednim katalogu pliku o odpowiedniej nazwie, po czym ładuje plik, tworzy instancje i ja zwraca.
Czy to jest wygodne czy nie to juz inna sprawa ale mozna takie rozwiazanie zmodyfikowac i poszerzyc o inne funkcjonalnosci dostosowane do swoich potrzeb.

Przyłączam się do pytania. Dzisiaj zauważyłem (i nie wiem dlaczego), że zaincludowanie klasy w głównym pliku/kontrolerze jest prawie 2x szybsze niż zainkludowanie w klasie statycznej. To tak przy okazji..

Wydaje mi się, że troszeczkę dochodzimy do granic abstrakcji :-)

90% wykonania funkcji autload to includowanie pliku i tego się nie ominie, niezależnie od tego czy includować będziemy za pomocą autoload czy ręcznie. Samo wywołanie tej funkcji zapewne "kosztuje" tyle co wywołanie każdej innej funkcji. Jest tak jak mówi Sh4adow - wszystko zależy od tego jak funkcja będzie napisana.

Ja osobiście robiłem testy na ZF - dopisałem do niego prosty autoloader dla własnych klas z mapą w pliku. Cóż mogę powiedzieć - funkcja zachowała się jak funkcja ;-) Wywołanie było dość kosztowne - ok 10-20% czasu wykonania skryptu jeśli dobrze pamiętam, ale to było spowodowane nie tyle samą funkcją co includowaniem samych plików. Wyników dokładnie nie pamiętam i nie mam ich już zapisanych, ale mój wniosek był mniej więcej taki:
- funkcja __autoload to dobre rozwiązanie i nie przynosi specjalnie dużych kosztów. Problem jaki się może pojawić to złe napisanie tej funkcji - np. brak mapy (czy jakiegoś jasnego układu) i każdorazowe przeszukiwanie folderów.

Ogólnie pytanie nie brzmi więc czy pisać autoloader tylko jak go napisać ;-) Ja z mojej metody jestem zadowolony. Dalsza optymalizacja, choć pewnie jest możliwa przy zwykłym projekcie nie ma większego sensu. Po prostu wzrost wydajności samego mechanizmu nawet o 100% nic konkretnego mi nie da, gdyż są to marginalne wartości.

uuu, temat trochę się zakurzył postanowiłem go rozruszać poprzez YAML:
YAML = mapa
wymyśliłem sobie że w __autoloadzie mamy (fragmenty):

[PHP] pobierz, plaintext 
<?php
function __autoload($sClassName) {
  $Autoload = Autoload::getInstance();
  //podajemy sciezke do pliku .yml
  $Autoload->setMapFile($map_file);
  //  importujemy mape z formatu YAML do przyjaznej tablicy
  $Autoload->importMapFile();
  [...]
  //  w strategicznym miejscu pilnujemy swiezosc mapy
  //  jako argument podajemy czas unixowy $t
  //  jesli wartosc $t>$tobecny-$t_ostaniaAktualizacja->akutalizuj()
  if(!$Autoload->isFileMapFresh(100))
  {
	$Autoload->addDir($ib_dir);
	$Autoload->addDir($data_dir);
   // ta metoda najpierw przeszukuje wskazane katalogi
   // wybiera pliki z rozszerzeniem .php
   //  zapisuje do tablicy['map'][nazwaklasy] = sciezka pelna do klasy
   //  nastepnie robimy export do pliku .yml
	$Autoload->setClassMap();
  }
  [...]
  //  require teraz to juz przyjemnosc
  if (!require_once $Autoload->getClassPath($sClassName);)
	{
	  //jakis blad
	};
}
?>
[PHP] pobierz, plaintext 

w YAML pieknie to wyglada

[SQL] pobierz, plaintext 
map:
  [nazwaklasy]:
    path: [sciezka do klasy]
[SQL] pobierz, plaintext 

Chce Ci się pisać te mapy w YAML? Bo nie widzę sensu, żeby generować je automatycznie - parser YAML będzie wolniejszy od wczytania zserializowanej tablicy... A to, że ładniej wygląda, to drugorzędna sprawa w przypadku autoloadera. Z resztą, czy zaimportowanie folderów do przeszukania jest brzydkie? Moim zdaniem nie...

[PHP] pobierz, plaintext 
<?php
function __autoload($classname){
	$path = "library".DIRECTORY_SEPARATOR."classes".DIRECTORY_SEPARATOR.str_replace("_", DIRECTORY_SEPARATOR , $classname).".class.php";
	if(!file_exists($path)){
		exit("Brak pliku: ".$path);
	}
	require_once($path);
	if(!class_exists($classname)){
		exit("Brak klasy: ".$classname);
	}
}
?>
[PHP] pobierz, plaintext 

A ja zawsze wykorzystywałem to:P kod nie jest długi, co o tym myślicie?

Ta funkcja wymaga aby wszystkie klasy były w jednym katalogu. Wydaje mi się, że w dyskusji chodzi raczej o rozwiązanie, które działa dla całej aplikacji. Gdy masz np. 20 katalogów z różnymi klasami to raczej nie ma sensu wykonywać tylu akcji plikowych i szukać w każdym katalogu danej klasy, także w średniej aplikacji to się raczej by nie sprawdziło.

athabus: W takim przypadku mapy się wydają być jedynym sensownym wyjściem, z punktu estetyki i także wydajności.

wiem i sam właśnie map używam

W klasie ClassLoader autora DjKermit brakuje warunku, który by nie przeglądał katalogów powstałych przez stosowanie programów do kontroli wersji np subversion.
Ponieważ gdy używa się kontroli wersji w każdym katalogu tworzy katalog .svn i w nich pliki.

I gdy próbuje się ładować wyskakuje błąd iż jest drugi raz ładowany plik.
Fatal error: Cannot redeclare class nazwaKlasy

Rozwiązałem poprzez dodanie warunku nie pozwalający przeglądać katalogi .svn lecz nie jestem autorem i nie poświęcałem uwagi gdzie powinno w sumie być jakiś dany warunek, który by nie ładował plików programu subversion.

[PHP] pobierz, plaintext 
<?php
private function readDir($path) {
		if ($handle = opendir($path)) {
			while (($file = readdir($handle)) !== false) { 
 
				if (is_file($path . $file) && strstr($file, 'class') && !strstr($file, 'ClassLoader')) {
					$this->readed_dir[str_replace('.class.php', '', $file)] = $path . $file;
				}else if (is_dir($path . $file) && $file != '.' && $file != '..' && $file != '.svn') {
					$this->readDir($path . $file . DIRECTORY_SEPARATOR);
				}//end if
			}//end while
			closedir($handle);
		}//end if
	}
?>
[PHP] pobierz, plaintext 

Nie wiem czy dobrze robie pisząc w tym temacie, zgłaszając taki błąd!!!.

Być może uznacie mnie za archeologa, ale temat był wg. mnie bardzo ciekawy, a przez 4 lata od ostatniego postu mogło się wiele rzeczy zmienić.
Czytając tą dyskusję doszedłem do dwóch wniosków.

Są dwie najbardziej 'wydajne' metody autoloadu plików w projekcie:
- mapper generujący tablicę ze skojarzonymi nazwami klas wraz z ich ścieżkami + autoloader bazujący na tych mapach,
- konwencja nazewnictwa PSR-0, polegająca na używaniu przestrzeni nazw w taki sposób, aby wskazywały na plik klasy.

Oba sposoby posiadają zalety i wady. Pierwszy wykorzystujący mapy jest bardziej elastyczny w stosunku do drugiego. Właściwie niezależnie jaką strukturę katalogów przyjmiemy, mapper przeskanuje nam ją i zwróci odpowiedni plik. Głównym problemem jest wielkość wczytywanej mapy, która niekoniecznie musi być wykorzystana w całości (jednak z każdym żądaniem musi być wczytana do zmiennej klasy). Sugestiami co do tego problemu jest rozbicie mapy na mniejsze 'podkategorie'.

Drugi sposób wydaje się bardziej wydajny w większy aplikacjach, gdzie ilość plików przekracza kilka setek. W tym przypadku, aby załadować klasę nie musimy wczytywać nic z zewnątrz co mogło by obciążyć aplikację. Posługujemy się tutaj przestrzenią nazw. Obiekt w swojej nazwie zawiera ściężke do pliku, w którym znajduje się klasa. Wymogiem jest tutaj odpowiednie nazewnictwo oraz zorganizowana struktura katalogów.

Od tamtej pory wiele rzeczy mogło się zmienić, dlatego zachęcam do dalszej dyskusji. Mnie głównie nurtuje rozwiązanie sposobu pierwszego, aby był on wydajny nawet przy większych systemach.

Pozdrawiam

Tak, tyle że w tym temacie, ktoś słusznie umieścił kod, przynajmniej moim zdaniem, żeby maper mapował jedynie pliki z odpowiednim zakończeniem, tj: *.class.php lub *.interface.php dzięki czemu pomijamy wiele plików które są ładowane już z poziomu samej biblioteki. U siebie coś takiego stosuje i serializowana tablica nie przekracza 10kb. A czy to jest dużo? Wątpię, ustawienia, czy i18n mają znacznie więcej. Większość bibliotek ma jakieś swoje loadery, lub też w jakiś swój sposób ładują inne klasy i te klasy są nie potrzebne nam w zasadzie bezpośrednio w mapie naszych klas, potrzebna nam jest klasa główna która pozostałe załaduje, jeżeli będzie taka potrzeba. I tak klasy które chcemy załadować poprzez loader dajemy z końcówką .class.php a tych których nie chcemy załadować dajemy bez tej końcówki, samo .php i nasza mapa plików znacznie się zmniejsza

Nie zaznaczyłem tego w swojej wypowiedzi, ale właśnie taki Autoloader miałem na myśli (wykorzystujący filtry suffixów). Zastanawiam się jednak, gdzie jest granica wielkości takiego wygenerowanego pliku i od jakiego rozmiaru zaczyna to wpływać na wydajność.

Co do innych propozycji, chodzi mi po głowie wyznaczenie Loaderowi tzw. "Core", czyli klas 'niskopoziomowych' systemu, które są zawsze ładowane przy każdym żądaniu. Klasy 'Core' byłyby przeparsowane do bytecodu, co przyspieszało by działanie aplikacji. Nie wiem jak dokładnie działają takie systemy cache (APC, MemCache). I tak końcowo by był:

Sparsowany core + autoload klas z mapy.

Pozdrawiam

Zacznijmy od tego, że w niewielkich projektach wydajność autoloadera nie ma znaczenia. Albo inaczej, jest bardzo mało prawdopodobne, aby to właśnie autoloader był przyczyną problemów z wydajnością.

W przypadku tych większych aplikacji standardem są akceleratory, które umożliwiają jednokrotne skompilowanie kodu do bytecodu i jego późniejsze wykorzystanie. Trzeba tutaj jednak zaznaczyć, że domyślnie większość (wszystkie?) akceleratory mimo wszystko każdorazowo sprawdzają czy aby przypadkiem źródło pliku się nie zmieniło. Operacje z wykorzystaniem dysku, nawet tak trywialne jak sprawdzenie daty modyfikacji pliku, są generalnie powolne co w przypadku gdy każdorazowo mamy do sprawdzenia setki plików może być problemem. Tutaj rozwiązania są dwa:
1. Wyłączyć takie sprawdzanie w konfiguracji akceleratora, np. dla APC będzie to dyrektywa apc.stat.
2. Stworzyć cache'a plików, tj. zebrać wszystkie pliki i wrzucić ich zawartość do jednego pliku. Dzięki temu ograniczymy się do pojedynczego sprawdzenia daty modyfikacji pliku.

W tym temacie jeden z użytkowników zamieścił właśnie takiego loadera, który sprawdzał suffixy, ale co to za problem samemu napisać proste wyrażenie "/([\w]+).(class|interface).php$/is" przy każdym dodanym pliku do tablicy wstawić preg_match i wyrażenie które podałem i wszystko. Kluczami są nazwy klas, wartością jest ścieżka bezwzględna. U mnie loader pierwsze przeładowanie sam tworzy cache w miejscu w którym znajduje się plik loadera. Kolejnymi sprawdzaniami zajmuje się pasywne cache które najzwyczajniej ponownie mapuje podane katalogi i tworzy cache.

Wydaje mi się że jest to najbardziej optymalne rozwiązanie, bo prawdę mówiąc loadery z przestrzenią nazw, również przeszukują tablice którą wcześniej mu się poda. No chyba żeby zrobić to na sztywno, gdzie przestrzeń nazw jest identyczna jak struktura katalogów. Tyle że mi takie rozwiązanie wcale nie przypadło do gustu. jestem w wielu przypadkach uzależniony od tego jak sobie ktoś zaprojektuje tą przestrzeń i robi się niekiedy burdel w katalogach, wtedy trzeba ręcznie poprawiać, a wole kiedy loader wie gdzie ma szukać klas, jak nie znajdzie znaczy że nie ma i syfu jako takiego nie ma. Oczywiście każdy ma inne przyzwyczajenia i upodobania.

@Crozin

Twój sposób numer dwa byłby bardzo dobry (sam tak kombinowałem), lecz jeszcze zanim wprowadzono namespace'y. Teraz próbując robić taki 'cache' (sklejke klas), jeżeli w pliku klasy jest oznaczona przestrzeń, a w kolejnej klasie tej przestrzeni nie ma to dojdzie do przypisania tej klasy do tego namespace'a. Zresztą opisywał już to Zyx w swoim wpisie o autoloaderze.

Zastanawiam się jednak czy jest narzędzie, które jest zdolne przetłumaczyć pliki PHP na bytecode generując plik z tym bytecodem. Póki co najwydajniejszym rozwiązaniem pozostaje autoloader oparty o mapy.

@Sagnitor: Nie widzę większych problemów:

[PHP] pobierz, plaintext 
<?php
 
namespace Project\NS1 {
	class NS1C1 { }
	class NS1C2 { }
}
 
namespace Project\NS2 {
	use Project\NS1\NS1C1;
	use Project\NS1\NS1C2;
 
	class NS2C1 { }
	class NS2C2 { }
}
 
namespace {
	class GC1 { }
	class GC2 { }
}
 
namespace Project\Test {
	use Project\NS1\NS1C1;
	use Project\NS1\NS1C2;
	use Project\NS2\NS2C1 as AbcNS2C1;
	use GC2;
 
	class Test {
	    public function __construct(NS1C1 $a, NS1C2 $b, AbcNS2C1 $c, GC2 $d) {
	        var_dump($a, $b, $c, $d);
	    }
	}
}
 
namespace XYZ {
	use Project\Test\Test;
 
	new Test(new \Project\NS1\NS1C1(), new \Project\NS1\NS1C2(), new \Project\NS2\NS2C1(), new \GC2());
}
[PHP] pobierz, plaintext 

Taki mechanizm jest nawet wykorzystywany w Symfony2.

A w jakim celu chciałbyś ten bytecode zapisywać na dysku?

Problem jest kiedy niektórzy piszą w ten sposób:

[PHP] pobierz, plaintext 
namespace Project\NS1;
 
class Foo
{
 
}
[PHP] pobierz, plaintext 

W sumie do końca kwestii bytecode'u nie przemyślałem. Podsumowując najlepsze rozwiązanie: sklejka + APC

Sagnitor -> mapa nie wyklucza stosowania konwencji PSR-0. Konwencja określa tylko, jak rozmieszczać klasy w plikach nazwanych w określony sposób i nie mówi nic o tym, że musi to być tłumaczone dynamicznie. Natomiast co do wydajności:

* Głównym parametrem jest obsługiwany ruch, a dopiero później wielkość serwisu. Nawet stosunkowo mały projekt przy dużym ruchu może znacząco zyskać, jeśli zmienimy strategię ładowania klas.
* Jest zauważalna różnica w czasie między korzystaniem z mapy klas, a dynamicznym tłumaczeniem. W tym drugim przypadku nawet w niezbyt dużych projektach tłumaczenie nazw klas na ścieżki potrafi zająć nawet do 40% łącznego czasu wykonania. Przynajmniej ja miałem takie wyniki przy zabawach profilerem, i mówię tu o naprawdę kompaktowej implementacji ładowarki. Jeśli mamy do czynienia z takimi kobyłami, jak Zend_Loader, to aż strach je mierzyć .
* Wielkość mapy ma znaczenie, jeśli w każdym żądaniu wczytujesz ją z pliku zapisanego na dysku. Możemy to wyeliminować, używając pamięci współdzielonej.
* Gdy mapa jest już wczytana do pamięci, zapisana jest w postaci tablicy z haszowaniem. Takie tablice charakteryzują się bardzo dobrym średnim czasem dostępu rzędu O(h), gdzie "h" to średnia głębokość pojedynczego kubełka. W praktyce h jest równe 1 lub nieznacznie tylko większe od jedynki.
* Mapa klas nie podlega zbyt częstym zmianom, a jeśli już, to przebudowujemy ją w całości na nasze wyraźne żądanie. Wtedy możemy zastosować w tablicy haszowanie perfekcyjne charakteryzujące się stałym czasem dostępu, niezależnym od wielkości tablicy. Teraz klas możemy mieć i milion; poza zajęciem kilkudziesięciu megabajtów RAM-u wydajność nie ulegnie zmianie.
* Skąd wziąć tablicę z haszowaniem perfekcyjnym w PHP? Ano np. z rozszerzenia chdb, które niedawno odkopałem w PECL-u.

Nawiasem mówiąc, sklejarkę plików o której wspominasz, zaimplementowałem kilka dni temu i jest już dostępna w repozytorium Open Power Autoloadera. Działa dobrze i po prostu zamienia zapis namespace XYZ; na namespace XYZ{ ... }, poprawnie radząc sobie również z plikami, które nie korzystają z przestrzeni nazw. Ale takie sklejanie ma nieco inny cel:

- w praktycznie każdej aplikacji możemy wyróżnić zbiór klas, który musimy zawsze załadować bez względu na to, co dane żądanie HTTP robi.
- dla takiego zbioru klas możemy w ogóle pominąć automatyczne ładowanie i wczytywać je ręcznie.
- jeśli korzystamy z APC, zapisywanie kodu bajtowego na dysku jest nam niepotrzebne, gdyż jest on trzymany w pamięci RAM.
- ALE: nawet jeśli mamy kod bajtowy zapisany już w RAM-ie, APC domyślnie wykonuje na każdym pliku operację stat, aby sprawdzić czy w międzyczasie plik nie uległ zmianom. Czyli jeśli mamy nasze klasy główne porozbijane na 100 plików, wciąż PHP wciąż wykonuje 100 operacji dyskowych mimo, iż ma już wszystko w pamięci. Jeśli skleimy je w jeden plik, zrobi się z tego jedna operacja.
- Oczywiście apc.stat pozwala to sprawdzanie wyłączyć, ale wtedy przy najmniejszej zmianie kodu (nawet głupiej poprawce szablonu HTML) będziemy musieli zrestartować serwer/PHP lub czekać, aż się cache zdezaktualizuje.
- Jeśli nie mamy APC, zysk ze sklejenia też jest i też wiąże się ze zmniejszeniem liczby operacji dyskowych (konkretniej otwieranie i zamykanie plików oraz wiążące się z tym przeszukiwanie ścieżek na dysku).

A to nie wystarczy już http://pl2.php.net/manual/pl/function.apc-store.php do przechowywania takiej "mapy" ?

Jak najbardziej wystarczy, tylko trzeba pamiętać o paru bolączkach APC:

- pamięć APC nie jest współdzielona między procesami,
- w szczególności nie możemy ze skryptu konsolowego wysłać polecenia wyczyszczenia cache i załadowania nowej mapy,
- aby zrobić coś takiego, musimy zrestartować procesy FastCGI lub Apache'a, ew. dodać do autoloadera jakiś przełącznik, który przeładuje mapę "przy najbliższym żądaniu", co może jednak wygenerować efekt wyścigu szczurów przy dużym obciążeniu,
- APC nie posiada tablicy z perfekcyjnym haszowaniem.

Dlaczego nie trzymać mapy autoloadera w memcached, bez problemu jest współdzielony przez wszystko na serwerze, ostatnio wykorzystywałem go nawet do pisania wielowątkowej aplikacji w PHP, jako warstwy komunikacji między procesami. Piekielnie wydajny, dobrze działa z PHP, widziałem nawet wirtualki, które go obsługują.

Przebudowanie mapy można zrzucić na na skrypt konsolowy odpalany w cronie np. co minutę, bądź w ogóle w momencie zmian na serwerze jako kolejne zadanie phinga.

Osobiście byłbym daleki od sklejania plików, przy odpowiedniej konfiguracji serwera najczęściej używane powinny być i tak trzymane w ramie.

Bo jest kilka razy wolniejszy od APC*, a sama mapa ma na tyle mały rozmiar, że każdy serwer spokojnie może ją trzymać we własnym RAM-ie. Ponadto zauważ, że jeśli każdy serwer może być aktualizowany niezależnie, to ja bym nie chciał nawet, by mapa klas była współdzielona, bowiem potencjalnie straszne rzeczy mogłyby się wtedy wydarzyć.

W ogóle dziwię się trochę, że tak dużo programistów próbuje robić w temacie systemów cache itd. jakieś wojny religijne na zasadzie "a to jest lepsze niż tamto". Bzdura. Każdy system, tak samo jak każdy algorytm ładowania klas ma swoje określone przeznaczenie. Jedne są optymalizowane pod jeden scenariusz, inne pod inny. Ważne jest, by znać właściwości i umieć to wszystko podobierać.

* - co nie powinno dziwić, jeśli weźmiemy pod uwagę, że bezpośredni odczyt z RAM-u zawsze będzie szybszy niż komunikacja przez warstwę sieciową systemu operacyjnego.

Jasna sprawa, możesz zrobić jeszcze jeden test dodając połączenie z memcache nie przez host i port, a za pomocą socketa? Myślę, że można jeszcze trochę pokręcić gałkami, po weekendzie postaram się znaleźć chwilę i powtórzyć twoje badanie z optymalizacją memcache, wydaje mi się, że różnica się zmniejszy do max 2/3 razy, co przy odpalaniu 1 raz na request usera robi się IMHO w zasadzie pomijalne (moja wersja jest taka, że cała mapa jest przechowywana pod jedym kluczem i na początku wczytywana przez aplikację, później wszystko odbywa się już w samym PHP).



Chyba wybór mniejszego zła. Jeżeli dobrze Cię rozumiem, APC ma swoją własną wersję np. dla każdej instancji Apache i w momencie wprowadzania zmian konieczny jest restart? Mając na serwerze np. Redmine na mod_passanger chciałbym mocno tego unikać.

Wykorzystanie gniazd uniksowych niewiele Ci da. Tracisz wtedy główną zaletę Memcached, a zyskujesz? W zasadzie nic, ponieważ zapytanie i odpowiedź wciąż musi przejść przez jądro systemu operacyjnego, gdzie są kilka razy kopiowane z jednego bufora do drugiego. Samo przełączanie się w tryb jądra również jest kosztowne. Żadne gniazda, żadne inne mechanizmy komunikacji międzyprocesowej nie są w stanie dorównać pamięci dzielonej.

Domyślnie w PHP każde żądanie traktowane jest jako zupełnie niezależny byt. Pojedynczy proces FastCGI lub moduł Apache'a może jednak przetwarzać wiele żądań jako osobne wątki. APC zezwala jedynie na wymianę informacji między tymi wątkami (kod bajtowy + dane), nie przekracza natomiast granicy procesu. Z tego powodu:
* W trybie modułu Apache'a dane są współdzielone jedynie między wątkami tego samego procesu Apache'a,
* W trybie FastCGI dane są współdzielone między wątkami tego samego procesu FastCGI.

Przy czym w FastCGI najczęściej uruchomionych jest równolegle kilka/kilkanaście procesów, które na dodatek mogą być co X żądań restartowane w celu eliminacji potencjalnych wycieków pamięci. APC nie pozwala ani na współdzielenie danych między tymi procesami (każdy proces jest odizolowany od drugiego), ani na manipulację nimi np. z poziomu skryptu konsolowego, ponieważ to jest jeszcze jeden proces. Podobnie, z tego co wiem, działa XCache. Z tego powodu jedynym 100%-pewnym sposobem wyczyszczenia cache jest tutaj restart Apache'a lub wszystkich procesów FastCGI.

Pamięć współdzielona to mechanizm pozwalający na zmapowanie pewnego fragmentu pamięci na przestrzeń adresową więcej niż jednego procesu. Oba te procesy widzą ten fragment jako "swój" i mają do niego pełne prawa odczytu oraz zapisu. Najczęściej współdzielony fragment reprezentuje się jako plik na dysku, który działa trochę jak pamięć wymiany - w momencie pierwszego użycia poszczególne jego bloki są importowane do pamięci i odpowiednio oznaczane. Gdy blok znajdzie się w pamięci, zasadniczo nie ma różnic wydajnościowych między dostępem do prywatnej pamięci procesu, a pamięcią współdzieloną. Wszystko wygląda fajnie, ale jest tutaj jeden problem, który tłumaczy dlaczego typowe akceleratory go nie wykorzystują: programista musi samodzielnie zaimplementować całe i w dodatku współbieżne zarządzanie takim obszarem pamięci, co nie jest zadaniem trywialnym. Jedynym znanym mi rozszerzeniem PHP, które wykorzystuje systemowy mechanizm pamięci dzielonej, jest wspomniany już chdb, który radzi sobie z powyższym problemem bardzo prosto: pamięć jest tylko do odczytu -> nie potrzeba żadnej synchronizacji -> nie trzeba implementować zarządzania taką pamięcią. Zawartość takiego cache można przebudować jedynie hurtem.

OK, ale chyba tyle na temat mechanizmów cache, ponieważ trochę zboczyliśmy z tematu. Mam nadzieję jednak, że rozwiałem tym wpisem wszelkie wątpliwości, dlaczego:
* nie powinno się stosować Memcached do obsługi map klas,
* dlaczego APC działa tak, jak działa.