Fragment wydzielony z topicu
http://forum.php.pl/viewtopic.php?t=3921[/... (DeyV)
-------------------------------------------------


scaner: ale to byly inne jezyki (jak i inne czasy). Dzis ludzie ucza sie od razu na jezykach wysokiego poziomu i nie maja pojecia co to jest zmienna, co to jest pamiec, jak to to jest zarzadzane...

DayV - jasne, ze mozna i ze robi sie tak. Pytanie tylko czy to maniera prawidlowa i czy tak wlasnie powinno sie nauczac? :wink:
Ja ignorowalem noticy dopoki przypadkiem nie przyszlo mi stawiac mojego skryptu na wlasnie takim serwerze jak opisalem... Od tego czasu zawsze pilnuje zeby nie bylo najmniejszego nawet bledu.

A swoja droga... no coz, sprawdzilem. Maszyna: Athlon 1.8Ghz, WinXP, Apache2, php 4.3.0:

Kod 1) w php.ini error_reporting = E_ALL & ~E_NOTICE

[php:1:db2ac36647]<?php
$m=0;
for ($i=0;$i<10000;$i++ ){
if($x) {
$m=1;
}
}
?>[/php:1:db2ac36647]

Wynik ab -n 300 - Requests per second: 40.76 [#/sec] (mean)

Kod 2) w php.ini error_reporting = E_ALL

[php:1:db2ac36647]<?php
$m=0;
for ($i=0;$i<10000;$i++ ){
if(isset($x)) {
$m=1;
}
}
?>[/php:1:db2ac36647]

Wynik ab -n 300 - Requests per second: 91.87 [#/sec] (mean)

No to chyba mam mocny argument?

Na szczescie nadal sa takie jezyki, w ktorych trzeba to robic.
Ciesze sie, ze od takich zaczynalem.

Przytocze moze taka fajna historyjke (ktora juz czesciowo opowiadalem DeyV'owi w drodze na PKP Poznan ).
Mam kumpla, ktory zaczal zabawe w programowanie od php, na poczatku szlo mu ciezko i w ogole, co chwile zawalal mnie glupimi pytaniami itp, ale teraz juz sie podszkolil i radzi sobie calkiem niezle sam.
Niedawno zaczal sie uczyc C++, ktorego ja juz troche znam, wiec oczywiscie tez bylem celem jego pytan.
Po dluzszej debacie (na gg) na temat jego problemu w C++ zadal mi pytanie, ktore mnie rozrobilo: "A to w C++ zmienne trzeba deklarowac? "

PS. e-Gandalf jak to zmierzyles? (te ab -n 300 malo mi mowi :/) bo argument calkiem mocny
-- ok juz wiem...

Co tu sie oszukiwac, przeciez na kazdym kroku, zwlaszcza (!!!), na grupach/forach o php widzimy przyklady skryptow, ktore w sposob karygodny ignoruja jakakolwiek ekonomie zarzadzania pamiecia. Kazdy skrypt deklarujacy na poczatku (czesto niepotrzebnie) ogromne wielowymiarowe tablice, i pozostawiajacy je az do konca... kazdy skrypt przyklad deklarowania setek zmiennych tymczasowych ktore nastepnie zostaja wylacznie raz uzyte. Kazdy przyklad $x=file() - a potem $x zostaje na zawsze. Przeciez to jest wlasnie glowne zagrozenie przy nauce programowania z php. Mila, niewinnie wygladajaca funkcja |file|, wygodna i szybka... slicznie. A potem niechcacy:

[php:1:c480e26c67]<?php
$x=file($_GET['file']);
?>[/php:1:c480e26c67]

i dziura gotowa... podajemy w urlu sciezke do np. pliku z /proc, albo logi apacha... skrypt ladujemy x razy i mamy obciazenie serwera = 100%.

Bardzo ciekawy test. Szczerze mówiąc wydawało mi się, że powinno być odwrotnie.
A tu naprawdę o połowę lepszy czas.
Ciekawe ednak jest, że w przypadku, gdy nasz $x jest wcześniej zadeklarowany, i to nizależnie od tego, czy to prosty int, czy też duży string, takiej różnicy już się nie zauważa. Praktycznie - czasy wtedy są identyczne. (porównywalne z przykładem 2)

Chyba jednak zmieniam zdanie
Sprawdzilem to troche doglebniej i sie okazuje, ze po pierwsze:
Ustawienie w php.ini E_NOTICE lub nie, nie powoduje zadnej (poza granica bledu pomiaru) roznicy. Czasy zmieniaja sie jedynie jesli zmienia sie sam sposob sprawdzania zmiennej. I teraz dodatkowym atutem if ($x) jest to, ze jest sprawdzane czy ta zmienna istnieje i czy jest rozna od "" (pusty string), wiec zeby osiagnac to samo kompatybilnie z E_NOTICE to trzeba by dac 2 warunki if(isset($x) && $x!="") co powoduje ze czasy sie praktycznie zrownuja w przypadku, gdy zmiennej nie ma, albo if($x) wyprzedza drugie konkurujace z nim rozwiazanie dosc znacznie jesli zmienna jest, wiec ten argument chyba wysiada ...

co prawda ja pracuję z wyłączonymi notice, ale, tak dla zasady, przypominam, ze zamiast kożystać z is_set, mozna użyć empty() i wtedy osiagniesz dokłądnie to samo, co chciałeś...

Dla ilu wynikow sprawdziles? Bo u mnie powoduje. Z bardzo naturalnej przyczyny - jesli mam wlaczone raportowanie NOTICE i sprawdzam if($x) to on musi wyswietlic X bledow (nie polaczonych ob wiec kazdy osobno) co spowalnia.



Zaraz! Stoj. Zdanie nielogiczne. Ja udowadnialem ze atutem if(isset($x)) jest szybkosc, zatem nie mozesz pisac ze "dodatkowym" atutem drugiej metody jest cos tam... wrrr..



Jak napisal DayV - nie prawda. Co wiecej. Skoro poruszyles juz ta sprawe, to przy okazji masz jeszcze wieksza swiadomosc programistyczna autora... Zamiast olewac wszystko co sie dzieje - istnienie zmiennej lub jej nie istnienie, zrownywac booleanowe false z "",'',0 itp... zaczynasz ROZUMIEC co oznaczaja konkretne instrukcje ukryte w tym jezyku wysokiego poziomu. Zacytuje ulubionego Dijkstre:



Ten facet napisal to 45 lat temu.... i prosze - jakie aktualne



I znowu - sprawdzales?

ogolnie przedstawie wyniki moich testow, ktore nie zgadzaja sie z tym co piszesz. A poniewaz piszesz bez powolywania sie na testy mam podejrzenia, ze testow wogule nie wykonales, a w zamian oparles sie na swojej znajomosci mechanizmow dzialania php - jak zwykle zreszta w takiej sytuacji - zawodnie.

1) metoda A

[php:1:ef3e6184c1]<?php
$m=0;
for ($i=0;$i<10000;$i++ ){
if($x) {
$m=1;
}
}
?>[/php:1:ef3e6184c1]


2) metoda B

[php:1:ef3e6184c1]<?php
$m=0;
for ($i=0;$i<10000;$i++ ){
if(isset($x)) {
$m=1;
}
}
?>[/php:1:ef3e6184c1]

3) metoda C

[php:1:ef3e6184c1]<?php
$m=0;
for ($i=0;$i<10000;$i++ ){
if(isset($x)&&$x!="") {
$m=1;
}
}
?>[/php:1:ef3e6184c1]


4) metoda D

[php:1:ef3e6184c1]<?php
$m=0;
for ($i=0;$i<10000;$i++ ){
if(!empty($x)) {
$m=1;
}
}
?>[/php:1:ef3e6184c1]

a) metoda A przy 'E_ALL & ~E_NOTICE' - ~40 prob na sekunde (1 proba 24 milisekundy)
metoda A przy 'E_ALL' - dzialalo tak wolno, ze skrocilem ilosc prob do 10 - ~0.03 wywolan na sekunde! (1 proba okolo 33 sekund!)
c) metoda B przy 'E_ALL & ~E_NOTICE' - ~95 prob na sekunde (1 proba okolo 10 milisekund)
d) metoda B przy 'E_ALL' - ~95 prob na sekunde (1 proba okolo 10 milisekund)
e) metoda C przy 'E_ALL & ~E_NOTICE' - ~87 prob na sekunde (1 proba okolo 12 milisekund)
f) metoda C przy 'E_ALL' - ~87 prob na sekunde (1 proba okolo 12 milisekund)
g) metoda D przy 'E_ALL & ~E_NOTICE' - ~87 prob na sekunde (1 proba okolo 12 milisekund)
h) metoda D przy 'E_ALL' - ~87 prob na sekunde (1 proba okolo 12 milisekund)

Co z tego wynika? Po pierwsze redukujemy wyrazy podobne : (g==h && e==f && c==d) => jesli obslugujemy bez noticow, nie ma znaczenia czy NOTICY sa wlaczone czy nie - to logiczne.

Najwolniejsze (i dziwie sie ze Tobie wyszlo inaczej) - jest wyswietlanie noticow, czyli metoda A (test a). Jest tak niesamowicie wolny, ze na naszym testcase nie ma co go sprawdzac (33 sekundy na strone)

Nastepne w kolejnosci jest "ukrywanie prawdy" - wylaczamy raportowanie NOTICE i uzywamy metody A (test .

Znacznie szybsze jest pelne kontrolowanie czy istnieje zmienna i czy nie jest pusta (jako dwa osobne wyrazenia) metoda C - to potwierdza moja teorie.

Porownywalna jest metoda D - z empty - daje Ci pelne mozliwosci jesli potrzebujesz sprawdzic zarowno istnienie zmiennej jak tez jej zawartosc (rzutowana na boolean). To znowu jest logiczne, bo ta metoda i metoda C sa rownowazne, przy czym empty jest krotsze w zapisie. Ma jeszcze jedna zalete, ktorej nie bralem pod uwage podczas testow - sprawdza takze czy (wiem - chore) tablica rzutowana na boolean jest T czy F.

Najszybsza jest metoda B z oczywistych wzgledow - sprawdzamy jedynie jeden warunek - istnienie zmiennej. I to jest najszybsze jesli potrzebujemy jedynie skontrolowac semafor istnieje/nie istnieje.

Jesli masz inne wyniki - prosze bardzo chetnie porownam.

musze przyznac ze bardzo ladna wypowiedz. *clap ;)


Pozdrawiam

Troche sie nie zrozumielismy...
Fakt, moj blad bo nie napisalem tego, po prostu przyjalem to za pewnik
Chodzi o to, ze wl./wyl. NOTICE nie powoduje roznic jesli zmienna x istnieje, bo jesli nie istnieje, to tak jak mowisz logiczne, ze musi spowalniac, bo musi wyswietlic bledy (znaczy NOTICE'y).


No tak, ale chodzilo mi o to, ze w if($x) zawiera sie kilka instrukcji, ktore sprawdzaja jeszcze czy nie jest to false, zero, badz pusty string.
Wiec if($x) jest w pewnym sensie dyskryminowany, bo on robi jeszcze pare innych rzeczy, wiec musi byc wolniejszy

Oczywiscie, ze sprawdzalem. Bez tego nie odwazylbym sie napisac.
Najpierw zrobilem testy, jak zobaczylem wyniki to napisalem.

patrz wyzej

Wszystko sie zgadza, bo Ty przeprowadzales testy dla sytuacji, w ktorej zmienna x nie jest zdefinowana, a ja sprawdzilem tez co sie dzieje kiedy $x jest ustawiony i wtedy wyniki sie troche odwracaja... if($x) jest wtedy szybszy niz if(isset($x)), stad te spore roznice.
Mam nadzieje, ze teraz sie rozumiemy
A sprawdzalem dla $x ustawionego, bo taka sytuacja zachodzi czesciej.

Hmm... Nie! Nadal sie nie zgadzamy.

Skoro tak sprawiasz problem, zatomizujmy go.
Bo wszystko zalezy od tego ktora z dwoch relacji wystepuje w naszym problemie:

1) Potrzebujemy sprawdzic czy zmienna rzutowana na boolean nie jest FALSE, ale (!!) jestesmy pewni, ze zmienna istnieje.

2) Potrzebujemy sprawdzic czy zmienna istnieje czy tez nie.

Zgodzisz sie chyba, ze zazwyczaj nastepuje jedna z tych dwoch relacji (bardzo zadko obie na raz) - albo zmienna np. otrzymujemy REQUESTem i wtedy nie jestemy pewni czy przyszla (lub jest deklarowana w bloku warunkowym itp.) albo zmienna jest deklarowana zawsze i chcemy tylko sprawdzic czy jest FALSE.

No to przypadek pierwszy:

A:
[php:1:e2193ca940]
<?
$m=0;
$x=0;
for ($i=0;$i<10000;$i++) {
$x=rand(0,1);
if ((bool)$x) {
$m=1;
}
}
?>
[/php:1:e2193ca940]
B:
[php:1:e2193ca940]
<?
$m=0;
$x=0;
for ($i=0;$i<10000;$i++) {
$x=rand(0,1);
if ($x) {
$m=1;
}
}
?>
[/php:1:e2193ca940]
a) A - ~34 req/sec
c) B - ~34 req/sec

Wyniki podane sa dla E_ALL, ale robilem je takze (dla uczciwosci) dla ~E_NOTICE - te same wyniki
Co wiecej, w tej sytuacji dla empty($x) tez otrzymuje te same wynki (w granicy bledu stat.)

A teraz przypadek drugi. Od razu uprzedzam, ze nie ma odniesienia do wynikow poprzednich, bowiem, jak slusznie zauwazyles, tamten test bazowal na zalozeniu ze sprawdzamy zmienna ktora nie istnieje i dobral (mam nadzieje, dosc jasno) optymalna metoda do tego. Jednak zadko sprawdzamy istnienie zmiennej nie majac choc cienia szansy ze takowa sie pojawi. Zatem nowy test:

A)
[php:1:e2193ca940]
<?
$m=0;
for ($i=0;$i<10000;$i++) {
unset($x);
$r = rand(0,1);
if ((bool)$r) {
$x=1;
}
if ($x) {
$m=1;
}
}
?>
[/php:1:e2193ca940]

[php:1:e2193ca940]
<?
$m=0;
for ($i=0;$i<10000;$i++) {
unset($x);
$r = rand(0,1);
if ((bool)$r) {
$x=1;
}
if (isset($x)) {
$m=1;
}
}
?>
[/php:1:e2193ca940]
a) test A + ~E_NOTICE (dla wlaczonego notice nie robilem bo po pierwsze juz wiemy jak to wyglada, po drugie nikt na stronie nie chce pokazywac chyba bledow? ) - ~20 req/sec
test B + E_ALL (dla E_NOTICE tez nie ma sensu robic, bo jak juz udowodnilismy, jesli unikamy noticow, to ich wyswietlanie lub nie nie wplywa na wydajnosc) - ~29 req/sec

Coz mamy? Po pierwsze sprowadzilismy problem do podloza - czyli licytacji czy lepiej wylaczyc notice i uzywacv skladni A czy wlaczyc i skladni B, po drugie... no coz... jednak moje?

Teraz dochodzimy do ostatniego punktu. A co jesli...?
A co jesli jednak w jakijs sytuacji (w jakims warunku) sprawdzasz i jedno i drugie? Przykladem takiej sytuacji niechaj bedzie - zmienna moze przyjsc z requesta i moze byc pusta (puste pole) - wowczas FALSE, inaczej TRUE.

I znowu, dzieki dwom wnioskom opisanym powyzej pozostaja nam dwa testy do sprawdzenia (zamiast wszystkich kombinacji)

A)
[php:1:e2193ca940]
<?
$m=0;
for ($i=0;$i<10000;$i++) {
unset($x);
$r = rand(0,1);
if ((bool)$r) {
$l = rand(0 , 1);
if ((bool)$l) {
$x='';
} else {
$x='aaa';
}
}
if (!empty($x)) {
$m=1;
}
}
?>
[/php:1:e2193ca940]

[php:1:e2193ca940]
<?
$m=0;
for ($i=0;$i<10000;$i++) {
unset($x);
$r = rand(0,1);
if ((bool)$r) {
$l = rand(0 , 1);
if ((bool)$l) {
$x='';
} else {
$x='aaa';
}
}
if ($x) {
$m=1;
}
}
?>
[/php:1:e2193ca940]
a) A + E_ALL - ~ 20 req/sec
B + ~E_NOTICE - ~ 15 req/sec

Wniosek? Nawet w przypadku gdy zajmujemy sie najszerszym mozliwym aspektem zastosowania konstrukcji if($x) nadal empty wygrywa. I to przy zalozeniu, ze w 50% sytuacji zmiennej x nie ma, w 25 jest i jest pozytywna, a jeszcze w 25% jest TRUE. A przeciez jesli zdarza sie przyklad ktory opisalem, to zdecydowanie wiecej jest odslon z pokazaniem formularza (zmiennej nie ma) niz z wyslaniem.

Ufff.... dobrze zrozumialem Twoje zalozenia?

Ogolnie wychodzi mi, ze lepiej jest zawezac wybor (co logiczne i czemu konstrukcja if($x) szkodzi ;p) a jesli sie nie da, stosowac jawne sprawdzanie.

Do tego dodam, powinno Ci sie spodobac, ze empty sprawdza tez czy tablica nie jest pusta... czyli ma wiecej zastosowan .

Ale to byla walka isset'a z if($x) a tutaj dochodzi nowy zawodnik empty

Albo sie myle, albo znowu ( ) wypatrzylem blad. Jest 50-50 ze zmienna jest lub jej nie ma (a nie 50-25, bo to niedopelnia nawet do 100% ) i 50-50 w jednym z tych poprzenich 50, ze zwroci TRUE, czyli upraszczajac 25%, ze bedzie TRUE, a 75% ze FALSE. Moze to miales na mysli, ale ja to inaczej odebralem.

No wlasnie to zalezy od sytuacji...
Tak jak mowisz jest ok, ale np. gdy GET'em przekazujemy dzial w ktorym jestesmy na stronie to 95% zmienna jest ustawiona, bo chyba rzadko ktos sobie sprawdza co sie stanie gdy nie bedzie
A jak juz pisalem i mierzylem przy zalozeniu, ze zmienna istnieje if($x) jest szybsze niz isset, chociaz ja wtedy stosuje switch'a i jest jeszcze lepiej, ale wiadomo o co chodzi (tylko przyklad nienajlepszy wybralem, ale pozno jest... wybacz ).

No tak, ale nie debatowalismy (a przynajmniej tak mi sie wydawalo i chyba nawet to gdzies zaznaczylem) nad tym jaka opcja jest lepsza tylko nad tym, czy isset jest szybszy od if($x)...
Podsumowanie:
Owszem jest szybszy, ale w przypadku, gdy zmienna sprawdzana nie istnieje, a wolniejszy w przeciwnym wypadku. Pozostaje tylko kwestia tego co w danej sytuacji zachodzi czesciej.
A biorac juz pod uwage nie tylko szybkosc ale i 'lepszosc' danego rozwiazania wygrywa isset (badz empty), o czym ja od poczatku wiedzialem, tylko nie o to mi chodzilo

Oczywiscie, ze mi sie podoba.

Nigdy nie wiesz kogo mam jeszcze w rekawie ;]



Dokladnie to Wybacz, pisalem to bedac zmeczony.



Tak. Oczywiscie. W wielu mozna zawezic, w niektorych nie da sie a i wtedy mozna analizowac ktore rozwiazanie bedzie szybsze



Hmmm... na pewno? Nie mierzylem tego, ale postaram sie to zrobic w niedziele. Wydawaloby mi sie to dziwne *^^*



No, mozna to sprowadzic do dyskusji na temat zasadnosci uzycia if($x)

[quote="FiDO"]
A biorac juz pod uwage nie tylko szybkosc ale i 'lepszosc' danego rozwiazania wygrywa isset (badz empty), o czym ja od poczatku wiedzialem, tylko nie o to mi chodzilo
[quote]

Pomijajac calkowita logicznosc powyzszego zdania przyznasz ze brzmi zabawnie

To może małe podsumowanie bo dyskusja ciekawa
Chodzi mi o to co lepiej używać i dla jakich sytuacji, oczywiście z ładnym komentarzem

Zmierzylem jeszcze raz i znowu mi tak wyszlo, tez wydalo mi sie to troche dziwne, ale tak mi wychodzi.

Jak ja pisalem to bylo jeszcze pozniej, wiec moze nie jest idealne.
...chociaz ja tam nie widze nic zabawnego, wydaje mi sie calkiem poprawne gramatycznie i logicznie (moze pomijajac slowo lepszosc, ktore wzialem w apostrofy dlatego)

to ze E_ALL ^ E_NOTICE jest wolniejsze jest logiczne

php zawsze generuje bledy NOTICE, tylko ze jak ustawisz E_ALL ^ E_NOTICE - nie sa one wyswietlane, ale generowane sa nadal ...

to samo dotyczy jak dajesz @ przed wyrazeniem

$ID = @$_GET['ID'];
$ID = isset($_GET['ID']) ? $_GET['ID'] : null;

oczyweiscie 2 przyklad w php bedzie szybciej dzialal - bo nie jest generowany blad

dlatego najlepiej stowrzy soibie jakas funkcje

function getParam($key)
{
return isset($_GET[$key]) ? $_GET[$key] : null;
}

$ID = getParam('ID');

Tak, jest to logiczne Tylko, ze logika nie zawsze dziala (w przypadku php nawet czesto nie dziala -> vide unset i zabawy z czasow php3 ;]). Dlatego czasem warto potestowac.

Ja teraz pisze skrypty tylko z error_reporting(E_ALL) i gwarantuje ze jesli bedzie dzialac skrypt to pojdzie wszedzie.
Bo z tego co wiem to domyslnie w php.ini jest wyswietlanie wszystkich bledow, ale wszyscy to zmieniaja zeby nie pokazywala bledow typu NOTICE, ciekawe czemu
Moze nie wszyscy potrafia programowac w php i wola zeby php ukrywalo ich bledy
To samo dotyczy register_globals, ciekawe czemu wszyscy je wlaczaja, przeciez tworcy php nie nadarmo ustawiaja ta opcje na domyslnie wylaczona. Nie chwalac sie moje skrypty dzialaja nie zalenie od tego czy register_globals jest wlaczone czy tez nie.

Tak sie sklada, ze domyslnie jest E_ALL & ~E_NOTICE, przynajmniej u mnie zawsze tak bylo domyslnie.
To ze wywali jakies notice'y niekoniecznie musi oznaczac blad/dziure. Jesli ktos wie dlaczego jest notice i wie, ze to nie ma wplywu na dzialanie skryptu w danej sytuacji to niekoniecznie musi przerabiac wszytsko na "E_NOTICE compatible"

To faktycznie masz sie czym pochwalic... pokaz mi tutaj jakas osobe, ktore stosuje register_globals on, nie liczac newbie.

NIe jest to może post na poziomei PRO, ale... warto o tym pamiętać, zę niektórzy prowajderzy narzucają ustawienia tego typu, częśto jest to właśnie register globals ustawione na on, i wtedy warto pamiętać o tym, by nie nadpisać sobie jakiś zmiennych (problem o którym kiedyś pisałem, tj. gdy masz zmiene $_GET['var'] i $_SESSION['var'] - przy off jest ok, ale przy on jedna z nich może zostać nadpisana)

Hmm, a mi sie zawsze wydawalo, ze jak jest register globals to po prostu do zmiennych globalnych o odpowiednich nazwach (tu: var) trafiaja odpowiednie wartosci z GET, SESSION, COOKIE itd. (wg odpowiedniej kolejnosci), i wtedy w tej zmienne globalnej mamy dostep tylko do jednej z wartosci "odziedziczonych" po GET, SESSION, przez co druga (i reszta jesli jest wiecej niz 2) zostala zignorowana (nie mamy do tej reszty dostepu przez zmienne globalne). Ale, ze tablice _GET, _POST itd. nie sa w ogole ruszane. Inaczej mowiac, ze skrypt napisany pod register_globals=off jest w pelni kompatybilny z register_globals=on. A z tego co piszesz wnioskuje, ze te tablice sa jednak ruszane :/

http://forum.php.pl/viewtopic.php?t=1465&h...ghlight=session

hmm, faktycznie... chociaz mi sie raczej nie zdarza dublowanie nazw, wiec poki co mam spokoj