PHP czy Java ?

cepa napisał(a)

wtf? a mi wszyscy dotychczas tlukli ze to czy java czy php to pierd a waskim gardlem jest baza

Znaczy się mySql, bo jak masz np. Oracle czy Postgresa to zazwyczaj nie ma problemów.

Krolik napisał(a)

*) dla dużego serwisu taniej wychodzi postawić jednego dedyka z Javą niż farmę serwerów na PHP.

wtf 2? a mi w robocie i na studiach wmawiano że koszt sprzętu to pryszcz, kosz programistów się liczy :/

A uwierz mi że o wiele taniej i szybciej jest dać napisać webowy front end na db lub portal społecznościowy programistą PHP. Zrobią to także lepiej od Javowców bo znaleźć dobrych font-endowców w tej grupie jest ciężko a jak back-end'owcy zabierają się za UI to się płakać chce (fu*kingh one-tab cookie masters :) ) .

Chociaż jeżeli chodzi o internetowe RIA to szala znów przechyla się na Javowców.

Zresztą to popytaj się wiary co pracowali w php'owym allegro co generuje im największe opóźnienia... Zastanów się czemu pompują multum kasy w pisanie własnych indeksów do MySQL'a i własnych narzędzi do cache'owania obrazków, a nie na przepisywaniu softu z PHP na Jave ? Wbrew pozorom są narzędzia żeby zrobić płynne przejście. Tylko po co przy tego typu aplikacjach...

Koziołek napisał(a)

Znaczy się mySql, bo jak masz np. Oracle czy Postgresa to zazwyczaj nie ma problemów.

Proszę cię...

MySQL bije na głowę Postgresa w mało współbieżnych środowiskach jakimi jest większość serwisów www.

Skąd ty wróżysz te z d* wzięte opinie...

Do wyroczni nie ma co porównywać MySQL bo to inna klasa. Ale powiedzenie że wstawienie oracla spowoduje że baza danych przestanie być wąskim gardłem w typowych bazodanówch serwisach (które stanowią 90% neta) jest idiotyczne.

Koziołek napisał(a)

Znaczy się mySql, bo jak masz np. Oracle czy Postgresa to zazwyczaj nie ma problemów.

postgres = problem
a postgres w srodowisku produkcyjnym to juz teksanska masakra a te jego kochane bledy z d**y...
juz nie wspominajac o takich szczegolach jak polskie slowniki do full text search czy dupiaty plpgsql, czasem naprawde wole zapomiec ze istnieje postgres, pisac pod mysql i spac spokojnie w nocy ze sie nic nie wyj*bie

mysql bez pierdniencia radzi sobie z bazami ponad 300MB na www i milionami rekordow w nich wiec imho nietrafiony zarzut

oracle nie znam to sie nie wypowiadam,

a wracajac do tematu:
dla klienta ktoremu najczesciej zwisa i powiewa czy projekt jest napisany w php javie czy innym brainfucku licza sie dwie rzeczy: budzet i termin, pomijajac flameowe kwestie w czym sie tworzy soft szybciej w php czy w javie, koszt tworzenia i utrzymania MALEJ aplikacji phpowej jest po prostu nizszy - masa "firm"-biedronek ktore robia za grosze i do tego tani i ogolno dostepny hosting,

schody zaczynaja sie gdy projekt sie rozrasta, mimo konsekwentnego stosowania mvc, utrzymanie w ryzach kilkuset klas w php jest trudne, kosztowne i czasochlonne glownie ze wzgledu na sam jezyk - brak kompilatora, brak typow, bledy z d**y, white screen of death, brak dokumentacji funkcji, brak stosowania wyjatkow, dupiaty ogolno dostepny kod

jako zawodowy programista php (zend, doctrine) stwierdzam ze php jest skur*ialy choc java pieknem tez nie grzeszy, ale do malych aplikacji webowych na tanim hostingu nie ma nic lepszego

• piszac wyzej php, mam na mysli zend, symphony itp wynalazki, bo pehape na poziomie gimnazjalnym to juz zupelnie inna kategoria [diabel]

@cepa, prowokujesz mnie by za wcześnie wrzucić tutka o Wickecie.

btw. postgres nie jest taki zły. Moja opinia wynika z produkcyjnego stosowania go w kilku dużych systemach (bazy po 2-3GB).
Co do Oracle to jego moc widać jak masz bazę 10gb i trzeba zrobić raport na wczoraj.
MySql jest z d#@y, jak jest coś małego to wolę użyć apache derby lub hsqldb, bo z mysqlem nie daje rady.

Swoją drogą to jest kolejna dyskusja prowadząca do niczego, bo wiadomo, że najlepszym językiem jest ulubiony.

Koziołek napisał(a)

Co do Oracle to jego moc widać jak masz bazę 10gb i trzeba zrobić raport na wczoraj.

Faktycznie feel the power... w MySQL to faktycznie marginesy nie równe wychodzą :P

Ja się zastanawiam czy moje zapytanie na dwie strony lokami nie zatrzyma produkcji gdy z kilka tygodni zmieni się profil zapytań zapuszczany z kolektorów danych.

Koziołek napisał(a)

MySql jest z d#@y, jak jest coś małego to wolę użyć apache derby lub hsqldb, bo z mysqlem nie daje rady.

Gratuluje decyzji. Faktycznie HSQLDB to RDBMS'y jak się patrzy ... w sam raz na produkcyjny serwer ...

Koziołek napisał(a)

Swoją drogą to jest kolejna dyskusja prowadząca do niczego, bo wiadomo, że najlepszym językiem jest ulubiony.

Ulubiony do czego ? tu jest właśnie problem że są ludzie którzy świadomie dobierają języki i narzędzia to konkretnego problemu i są tacy jak ty który wciska wszędzie bez namysłu Jave. (lub też .NET)

Janusz Filipiak prezes ComArchu powiedział kiedyś "każdego specjalistę można zastąpić skończoną liczbą studentów". Oczywiście Javę czy .NET też można zastąpić... PHP

i tyle w tym temacie ;)

Ciekawe, że dawni obrońcy PHP teraz jadą po tym języku ;-P

endl napisał(a)

Ciekawe, że dawni obrońcy PHP teraz jadą po tym języku ;-P

Mało kto wie, że Janusz Filipiak mówiąc ten kultowy tekst dopowiedział jeszcze coś po pauzie:
"każdego specjalistę można zastąpić skończoną liczbą studentów... zazwyczaj jednym" ;)

Nadal uważam, że PHP to dobry i atrakcyjny produkt ale porównywanie go do Javy i .NET już nie jest poważne i świetnie pasuje do tego cytat Filipiaka :) PHP świetnie nadaje się do tworzenia stron od prostych do bardzo rozbudowanych serwisów ale są zastosowania do których nie nadaje się ani PHP... ani student ;)

Na sam poczatek bym chyba wybral PHP - latwo zobaczyc wyniki, mozna sie pochwalic kolegom przez neta, nie ma problemow z typami. Mozna w miare szybk sprawdzic czy jest sie stworzonym do programowania cyz nie, czy to kogos bawi czy nie. Co do czytelnisci i poprawnego pisania kodu to nie sadze ze taki zielony programita w JAvie zacznie od razu korzystac z DRY, KISS, MVC i czegotam nie wymyslicie.
Jak juz sie dowiem czy programiwani mnie bawi i chce sie tym zajmowac to bym jak najszybciej sie przesiadl na inny jezyk.

@endl, zmądrzeli.

@walec51, produkcyjnie wykorzystuję Oracle od dłuższego już czasu. Wszędzie tam, gdzie klienta na to stać. Postgres tam gdzie klient chce zaoszczędzić, a mySqla próbowałem użyć w testach z DBUnit i niestety wymiękał. HSQLDB czy derby łatwo posprzątać po zakończeniu testów. mySql już tak łatwo się nie poddaje.
Javy tez nie wciskam wszędzie. Powiedział bym to raczej o JVM, bo często gęsto wykorzystuję skrypty w Ruby, Scali czy Drools, które uruchamiam na JVM.

schody zaczynaja sie gdy projekt sie rozrasta, mimo konsekwentnego stosowania mvc, utrzymanie w ryzach kilkuset klas w php jest trudne, kosztowne i czasochlonne glownie ze wzgledu na sam jezyk - brak kompilatora, brak typow, bledy z d**y, white screen of death, brak dokumentacji funkcji, brak stosowania wyjatkow, dupiaty ogolno dostepny kod

Cepa, dokładnie to chciałem powiedzieć. PHP jest fantastycznym językiem do prostych projektów (hehe, moja stronka www.stackprobe.com stoi na PHP właśnie ze względu na prostotę i tani hosting). Problem w tym, że wiele serwisów się rozrasta i wtedy przestaje się robić tak wesoło. Za twierdzenie, że "zawsze baza nie wyrabia" są niestety odpowiedzialne właśnie takie przerośnięte projekty w PHP. Dobre zrealizowanie buforowania warstwy danych w PHPie jest o wiele trudniejsze niż w takim ASP.NET czy J2EE, gdzie takie rzeczy są out-of-the-box i to działające STABILNIE. Podobnie jest z frameworkami MVC - MVC jest dla PHP bardzo nienaturalne - wszystkie obiekty tworzone przy każdym wywołaniu skryptu - i to ma być wydajne i proste?

PHP jest jak kombinerki. Do wbijania małych gwoździ w sam raz, bo nie trzeba brać niewygodnego dużego młotka, no i są zawsze gdzieś pod ręką. Ale do dużych gwoździ trochę ciężko idzie.

Krolik napisał(a)

Problem w tym, że wiele serwisów się rozrasta i wtedy przestaje się robić tak wesoło. Za twierdzenie, że "zawsze baza nie wyrabia" są niestety odpowiedzialne właśnie takie przerośnięte projekty w PHP.

Problem w tym że większość serwisów się NIE rozrasta i pada po roku działalności. W tej branży jak nie masz hojnego inwestora za plecami bardziej się liczy możliwość taniego prototypownia serwisów. Jak się przyjmą to i znajdą się pieniądze na ich rozwój w pierwotnej technologi lub przepisanie na inną. Idiotyzmem jest robić future driven development w tak niepewnych projektach.

Allegro, Amazon jakoś sobie radzą z PHP.

Co to tego że baza nie wyrabia to to doświadczenie bardziej czerpie z projektów w Javie i C++ niż PHP bo ich realizowałem więcej. Projekty na które mówię 'typowa bazodanówka' po prostu tak mają.

walec51 napisał(a)

Problem w tym że większość serwisów się NIE rozrasta i pada po roku działalności. W tej branży jak nie masz hojnego inwestora za plecami bardziej się liczy możliwość taniego prototypownia serwisów. Jak się przyjmą to i znajdą się pieniądze na ich rozwój w pierwotnej technologi lub przepisanie na inną. Idiotyzmem jest robić future driven development w tak niepewnych projektach.

ja pisze z punktu widzenia programisty - to ze serwis sie rozrasta / nierozrasta to problem klienta, ale w firmie korzystasz z kodu ktory powstaje nabierzaco i sie nawarstwia, jak zjebiesz na poczatku to po kilku projektach zaczyna sie rzezbienie w gownie

Krolik napisał(a)

Podobnie jest z frameworkami MVC - MVC jest dla PHP bardzo nienaturalne - wszystkie obiekty tworzone przy każdym wywołaniu skryptu - i to ma być wydajne i proste?

no wczoraj wlasnie testowalem na produkcji aplikacje w Zend + Doctrine (kuupa kodu, klas itd), z wlaczonym mod_mem_cache oraz apc, no i kurde czas generacji strony na poziomie 0.3 przy pierwszym requescie i 0.03 przy nastepnych :o, jednym slowem tragedii nie ma :)

Ty to nazywasz tragedii nie ma, a my obecnie mamy (system PRZED optymalizacją):

• pierwsza odsłona: ~50ms
• następne kilkanaście odsłon: ~3-10ms
• po ok. 100 zapytaniach: ~0.5 ms

Spokojnie ciągniemy 2,5 tys. żądań/s z jednego serwera. To jest ponad rząd wielkości różnicy ;)

Atak numerków z d*py. Ten sam system, ta sama strona w php, różne komputery do developerki (żadne tam serwery):
wynik dla kompa A: 1224 ms
wynik dla kompa B: 46 ms

Wniosek, komputer B ma lepsza wersje PHP i to nawet o dwa rzędy wielkości.

Nikt z was nie podał jakie to projekty, jakie maszyny i jakie serwery :/

Przypomina mi to scenkę z Dilberta gdzie na prezentacji mówi:

Nie potrafiłem zrobić dokładnej wyceny więc wymyśliłem liczbę 4'556'234,56 $ Badania dowiodły że tego typu wymyślone liczby są statystycznie tak samo trafne jak wyniki analiz.

Ile badań to dowiodło?

83 ...

Nie widziałem jeszcze dużego serwisu napisanego w PHP, który potrafiłby przekroczyć 100 żądań/s na mocnej developerskiej maszynie. A mamy w robocie kilka serwisów opartych na gotowcach w PHPie i kilka serwisów w J2EE. Oczywiście, macie rację, że różnice wynikające z tego, że to różne serwisy, mogą być znaczne, ale nie ulega wątpliwości (i to już było sprawdzane w lepiej kontrolowanych warunkach), że:

1. Interpreter PHP wykonuje kod dużo wolniej niż wykonuje się zoptymalizowany kod natywny. Nawet ze wszystkimi przyspieszaczami, cache'ami bajtkodu jest nadal daleko w tyle. Jako dużo wolniej rozumiem 10-100x wolniej, a nie kilka %.
2. Stworzenie wydajnego kompilatora JIT/HotSpot dla języków dynamicznie typowanych graniczy z cudem i nikomu się to jeszcze nie udało. Największe szanse na bycie wydajną platformą wykonawczą dla PHP, Rybyego i Pythona ma JVM 7 - po wprowadzeniu invokedynamic.
3. Implementacja PHP na JVM jest szybsza niż oficjalna implementacja PHP w C. Przynajmniej tak było w 2005 roku: http://scott.yang.id.au/2005/12/faster-php-on-resinjvm/
4. Dla rozbudowanych aplikacji korzystających z MVC ilość obliczeń wykonywanych przez kod frontendowy może być dosyć pokaźna. Tzn. często wąskim gardłem jest baza danych, ale nie zawsze.
5. W Javie się dużo łatwiej buforuje różne rzeczy niż w PHP. Czy PHP potrafi coś takiego:

@Cached(timeout = 3600000)
List<String> getMostPopularUsers() {
...
}

? Mając odpowiednio skonfigurowany projekt, żeby buforować wynik metody wystarczy dodać odpowiednią adnotację.

Ja tam nie twierdze, że PHP jest demonem szybkości, ale dla mnie jest fast enough.

Krolik napisał(a)

1. W Javie się dużo łatwiej buforuje różne rzeczy niż w PHP. Czy PHP potrafi coś takiego:

@Cached(timeout = 3600000)
List<String> getMostPopularUsers() {
...
}

No w PHP nie ma adnotacji. Jako, że PHP używam raczej z przymusu niż z zamiłowania i nie znam żadnych raw PHP sztuczek, pokaże jak to wygląda we frameworku symfony:

```php
$cache = new sfFileCache(array('lifetime' => 3600000, 'cache_dir' => sfConfig::get('sf_cache_dir').'/function'));
$fc = new sfFunctionCache($cache);

$result = $fc->call('getMostPopularUsers()');

Oczywiście cache mogą być róznego rodzaju.

Bueee... czyli żeby dodać cache do jakiejś metody muszę zmienić tylko wszystkie jej wywołania. :>
I z tego, co widzę w dokumentacji symfony, dane są trzymane na dysku, w memcached lub w bazie danych. 100x szybsza opcja - w pamięci procesu - gdzie? Hmm... proces ginie po obsłużeniu wywołania. A to feler. :-P A to wywołanie metody za pomocą jej nazwy w stringu to na pewno bardzo szybkie jest. Nie mówiąc już, że też bardzo eleganckie i czytelne. [green]

Musisz postarać się, bardziej, żeby zbić argument 5.

Krolik napisał(a)

Bueee... czyli żeby dodać cache do jakiejś metody muszę zmienić tylko wszystkie jej wywołania. :>

Tam wszystkie, wystarczy zmienic metode i returnowac to co zwróci call. :P

Krolik napisał(a)

I z tego, co widzę w dokumentacji symfony, dane są trzymane na dysku, w memcached lub w bazie danych.
100x szybsza opcja - w pamięci procesu - gdzie? Hmm... proces ginie po obsłużeniu wywołania. A to feler.

Imo memached to jakas namiastka tego.

Krolik napisał(a)

A to wywołanie metody za pomocą jej nazwy w stringu to na pewno bardzo szybkie jest. Nie mówiąc już, że też bardzo eleganckie i czytelne.

'MojaKlasa::mojaMetoda', czytelniej sie nie da. Co do szybkosci, to nie widziałem implementacji/nie znam się więc nie będę się wypowiadał :P Natomiast ciekaw jestem co się kryje za tą adnotacją.

Krolik napisał(a)

Bueee... czyli żeby dodać cache do jakiejś metody muszę zmienić tylko wszystkie jej wywołania. :>
I z tego, co widzę w dokumentacji symfony, dane są trzymane na dysku, w memcached lub w bazie danych. 100x szybsza opcja - w pamięci procesu - gdzie? Hmm... proces ginie po obsłużeniu wywołania. A to feler. :-P A to wywołanie metody za pomocą jej nazwy w stringu to na pewno bardzo szybkie jest. Nie mówiąc już, że też bardzo eleganckie i czytelne. [green]

Musisz postarać się, bardziej, żeby zbić argument 5.

Z tej argumentacji wynika tylko tyle że nie wiesz co można zrobić w językach dynamicznych żeby zapisać to znacznie krócej i mniej inwazyjnej. Czyli np. poprzez jeden adapter na parę lini kodu, który zapewni cachowanie dla wszystkich klas wtedy kiedy tylko tego zechcemy.

poza tym w produkcji zazwyczaj zamiast adnotacji typu @Cached(timeout = 3600000) widzę XML'ki i tu twoja bajka o przejrzystości się kończy.

Krolik napisał(a)

Bueee... czyli żeby dodać cache do jakiejś metody muszę zmienić tylko wszystkie jej wywołania. :>
I z tego, co widzę w dokumentacji symfony, dane są trzymane na dysku, w memcached lub w bazie danych. 100x szybsza opcja - w pamięci procesu - gdzie? Hmm... proces ginie po obsłużeniu wywołania. A to feler.

Co z tego że proces ginie jak zmienne sesyjne leżą w pamięci współdzielonej procesów.

Gdzie tu różnic czasowych w dostępie.

100x szybsza opcja ?! w porównaniu do czego?

Java troll ...

PS.

To że za obsługa php jest oparta na procesach (de facto obsługa apache) sprawia problem. Ale zupełnie gdzie indziej i bynajmniej wątpię żebyś to dostrzegł za kadencji tego wątku na forum :P

Weź sobie porównaj, ile trwa synchronizowane pozyskanie danych przez IPC z pamięci współdzielonej, a ile wzięcie ich bezpośrednio z pamięci lokalnej dla wątku i przestaj gadać głupoty. Po zlikwidowaniu synchronized w ehcache uzyskano 60 krotne przyspieszenie.

Czyli np. poprzez jeden adapter, który zapewni cachowanie dla wszystkich klas kiedy tylko tego zechcemy

To ja proszę o ten adapter i przykład zastosowania do jednej metody.

Krolik, a nie wierzysz ze sie da? Ja poprosze implementacje tego interceptora ktory obrabia @Cached i calego frameworka ktore ten cache trzyma. Tez jest niemalo kodu.
Walec, to ze pobiertanie danych z pamieci wspoldzielonej procesow jest wolniejsze od brania danych z jednego procesu, to chyba nie ma zadnych watpliwosci?

Trochę kodu jest, choć połowa wygenerowana z automatu (praktycznie cały CacheKey jest wygenerowany Eclipsem):

@Aspect
public class CachedAspect {

	private static Log logger = LogFactory.getLog(CachedAspect.class);
	
	private String cacheManagerConfigFile = "conf/ehcache-spring.xml";
	
	private CacheManager cacheManager = new CacheManager(cacheManagerConfigFile);
	
	public void init() {
		cacheManager.addCache(Cached.DEFAULT_CACHE_NAME);
	}
	
	
	@Around(value = "@annotation(cached)")
	public Object doCached(final ProceedingJoinPoint pjp, final Cached cached) throws Throwable {
		Object[] arguments = pjp.getArgs();		
		Cache cache = cacheManager.getCache(cached.cacheName());
		CacheKey ck = new CacheKey(pjp.getSignature().toLongString(), arguments);
		if (cache == null)
			logger.error("Cache " + cached.cacheName() + " was not configured.");
		else {
			Element cachedVal = cache.get(ck);
			if (cachedVal != null) {
				logger.debug("Method cache hit for: " + pjp.getSignature().toLongString());
				return cachedVal.getObjectValue();
			}
		}

		logger.debug("Method cache miss for: " + pjp.getSignature().toLongString());
		Object retVal = pjp.proceed();
		
		if (cache != null)
		    cache.put(new Element(ck, retVal));
		return retVal;
	}

	
		
	public void setCacheManagerConfigFile(String cacheManagerConfigFile) {
		this.cacheManagerConfigFile = cacheManagerConfigFile;
	}	
}


class CacheKey implements Serializable {
	private static final long serialVersionUID = -7261795681045793779L;
	
	private String signature;
	private Object[] args;
	
	public CacheKey(String signature, Object[] args) {
		super();
		this.signature = signature;
		this.args = args;
	}

	@Override
	public int hashCode() {
		final int prime = 31;
		int result = 1;
		result = prime * result + Arrays.hashCode(args);
		result = prime * result
				+ ((signature == null) ? 0 : signature.hashCode());
		return result;
	}

	@Override
	public boolean equals(Object obj) {
		if (this == obj)
			return true;
		if (obj == null)
			return false;
		if (getClass() != obj.getClass())
			return false;
		CacheKey other = (CacheKey) obj;
		if (!Arrays.equals(args, other.args))
			return false;
		if (signature == null) {
			if (other.signature != null)
				return false;
		} else if (!signature.equals(other.signature))
			return false;
		return true;
	}	
}

Cała reszta to otwarte biblioteki: EhCache + Spring Framework + AspectJ.

Krolik napisał(a)

Weź sobie porównaj, ile trwa synchronizowane pozyskanie danych przez IPC z pamięci współdzielonej, a ile wzięcie ich bezpośrednio z pamięci lokalnej dla wątku i przestaj gadać głupoty. Po zlikwidowaniu synchronized w ehcache uzyskano 60 krotne przyspieszenie.

A co mnie obchodzi IPC realizowane w Javowym sofcie w jvm'ie.

Weź mózgu sobie czytnij:

http://www.advancedlinuxprogramming.com/

rodział 5.1.1 pierwszy paragraf.

Shared memory is the fastest form of interprocess communication because all
processes share the same piece of memory.Access to this shared memory is as fast as
accessing a process’ s nonshared memory, and it does not require a system call or entry
to the kernel. It also avoids copying data unnecessarily.

Problemy z synchronizacją są takie same jak w aplikacji wielowątkowej.

Kod adaptera? później

troll ...

@Around(value = "@annotation(cached)")

czyli kolejna adnotacja awymagajaca jakiegos spring-aop lub innego cuda. Tez warstwa na wastwie na warstwie. I do tego to nie jest wcale eleganckie, anie tzw type-safe, value przekazywana jest w postaci stringa (czepiales sie nazwy metody jako stringa).

walec51 napisał(a)

Krolik napisał(a)

Weź sobie porównaj, ile trwa synchronizowane pozyskanie danych przez IPC z pamięci współdzielonej, a ile wzięcie ich bezpośrednio z pamięci lokalnej dla wątku i przestaj gadać głupoty. Po zlikwidowaniu synchronized w ehcache uzyskano 60 krotne przyspieszenie.

A co mnie obchodzi IPC realizowane w Javowym sofcie w jvm'ie.

Weź mózgu sobie czytnij:

http://www.advancedlinuxprogramming.com/

rodział 5.1.1 pierwszy paragraf.

Shared memory is the fastest form of interprocess communication because all
processes share the same piece of memory.Access to this shared memory is as fast as
accessing a process’ s nonshared memory, and it does not require a system call or entry
to the kernel. It also avoids copying data unnecessarily.

Wszystko prawda, tylko żeby dostać wskaźnik do przestrzeni współdzielonej NAJPIERW ta pamięć musi być zamapowana w przestrzeń wirtualną procesu. I tu jak najbardziej są potrzebne wywołania systemowe (shmget) i dokonanie odpowiednich wpisów do dwupoziomowej tablicy mapowania stron przez kernel, co wcale nie jest takie tanie w porównaniu z korzystaniem później ze wskaźnika. Owszem, później używanie wskaźnika jest tak samo szybkie (zresztą pod Windows jest tak samo) jak normalnego, tzn. to jest normalny wskaźnik.

Dane eksperymentalne mówią same za siebie, że buforowanie w lokalnej pamięci procesu jest 2 rzędy wielkości szybsze:

Tu masz przykładowe porównanie memcached i EhCache:
http://gregluck.com/blog/archives/2007/05/comparing_memca.html

Zresztą to jest główny zarzut do tego benchmarku, że jest nie fair, bo EhCache korzysta z pamięci lokalnej, a memcache jest rozproszony i jedzie po TCP/IP z serializacją.
Ale, ale, APC korzysta przecież z IPC. Zobaczmy. Zgodnie z tym co piszecie, powinno być dużo szybsze. Niestety: http://www.phpbuilder.com/board/archive/index.php/t-10346692.html

Wypada czasem tylko "nieco" lepiej niż memcached. Do dwóch rzędów wielkości jeszcze bardzo daleko.
Może to dostęp do wskaźników w PHP jest taki powolny? I to mimo APC? Dziwneee..... :-P
Ten benchmark zresztą jest mało realistyczny bo wszystko robi w jednym skrypcie, zawyżając wyniki, unikając właśnie kosztów uzyskania dostępu do pamięci współdzielonej (mam nadzieję, że APC robi to tylko na początku - raz na wywołanie skryptu).

Wniosek: co byś nie zrobił buforowanie danych w PHP jest na razie o 2 rzędy wielkości wolniejsze i tyle. Możliwe, że TEORETYCZNIE da się to rozwiązać, ale na razie nie ma dla PHP równie wydajnego rozwiązania co EhCache i inne cache Javowe (EhCache jest najpopularniejszy - ale znam co najmniej 5 innych implementacji).

Tez warstwa na wastwie na warstwie.

Różnica jest taka, że w Javie warstwy na warstwach na warstwach działają o wiele szybciej niż PHP. Tutaj wywołania metod są robione bezpośrednio przez CALL procesora, a nie za pośrednictwem hashmapy czy innego badziewia symulującego obiekty. Wiele krótkich wywołań jest automatycznie robionych inline. Podobnie odczyt pól obiektu - korzystanie z rejestrów procesora jest naprawdę dużo szybsze niż hashmapa w interpreterze bajtkodu PHP.

I do tego to nie jest wcale eleganckie, anie tzw type-safe, value przekazywana jest w postaci stringa

Przyganiał kocioł garnkowi. Zacznijmy od tego, że PHP całe nie jest type-safe.
Adnotacje w Javie są typesafe - tylko że twórcy AspectJ stwierdzili, że zrobią własny język opisu joinpointów, więc zmuszeni zostali by to wpisywać w stringach. Ale co z tego - to jest JEDNA adnotacja siedząca sobie w kodzie bibliotecznym. A nie dla każdej buforowanej metody. Nie czaisz różnicy?

Nie jest tylko w kodzie bibliotecznym, skoro znalazla sie w Twoim kodzie.
Na marginesie, niee unos sie, podchodzisz dosc osobiscie do tego tematu. (Walec podchodzi jeszcze bardziej osobiscie i jest wrecz agresywny w swoim stylu pisania, nie musisz rownac do tego poziomu). Poza tym, ja rowniez jestem programista javy, wiem co to aspectj i podobne, wiem ze adnotacje sa type-safe, wiem rowniez ile kodu i jaki narzut jest zeby refleksyjnie wyboerac metody ktore adnotacje maja (dlatego czesto kozysta sie z np asm), co nie zmienia faktu ze i php ma swoje miejsce, i ogolnie rozmowy typu "java jest lepsza niz php bo..., php jest lepsze bo..." chyba nie przystaja osobie o Twojej renomie na tym forum?
Pozdrawaim.

wujek_srujek napisał(a)

Nie jest tylko w kodzie bibliotecznym, skoro znalazla sie w Twoim kodzie.

Ok, ale ten kod jest częścią biblioteki, którą używamy w wielu projektach. Raz dołączam jedną jarkę do projektu i mogę korzystać wszędzie z @Cached.

Na marginesie, niee unos sie, podchodzisz dosc osobiscie do tego tematu. (Walec podchodzi jeszcze bardziej osobiscie i jest wrecz agresywny w swoim stylu pisania, nie musisz rownac do tego poziomu). Poza tym, ja rowniez jestem programista javy, wiem co to aspectj i podobne, wiem ze adnotacje sa type-safe, wiem rowniez ile kodu i jaki narzut jest zeby refleksyjnie wyboerac metody ktore adnotacje maja (dlatego czesto kozysta sie z np asm), co nie zmienia faktu ze i php ma swoje miejsce, i ogolnie rozmowy typu "java jest lepsza niz php bo..., php jest lepsze bo..." chyba nie przystaja osobie o Twojej renomie na tym forum?
Pozdrawaim.

Ależ ja się wcale nie unoszę. Wcześniej w wątku napisałem, że PHP ma swoje miejsce i że sam piszę często mniejsze rzeczy w PHPie. Ba, PHP bardzo ładnie współgra z Javą jako warstwa prezentacji.

Natomiast trochę denerwuje mnie, jak ktoś próbuje udowadniać, że PHP z powodzeniem ZASTĘPUJE Javę w dużych projektach (i jest przy tym tak samo wydajne, hehe). Niedługo będę prowadził szkolenie w jednej dużej znanej firmie, która dotąd robiła głównie w PHPie i w końcu powiedzieli dość - migrują na Javę bo w PHPie nie radzą sobie jak się im projekt zaczął rozrastać. Zarówno z pielęgnacją kodu jak i z uzyskaniem wystarczającej wydajności.

Tak samo denerwowałoby mnie jakby ktoś wykazywał, że Java jest świetna do hostowania małych stron dynamicznych (dopóki nie będzie MVM, to taniego hostingu aplikacji Javowych nie będzie).