|
Skraćenice i optimizacija
Nešto gledam i pitam se ko od vas sve koristi skraćenice zarad brzine a ko zarad optimizacije aplikacije
recimo ovo PHP kôd:
PHP kôd:
|
Što se tiče prvog primera, ne koristim ni jedan ni drugi. :)
Već ovako: PHP kôd:
Što se tiče drugog primera, uvek težim da koristim if-else petlju pre nego tzv "ternarni operator", pre svega zato što smatram da je onda kod čitljiviji. |
Prvu nikad ne koristim jer onda imam problema sa XML-om (<? je rezervisano za XML proccessing instrukcije). S obzirom da (gotovo uvek) šaljem XHTML 1.1, ne koristim istu.
Takođe, ne vidim kako si ubrzao ili optimizovao aplikaciju ako si izostavio 3 karaktera? Jedino ako misliš na nekog programera kome je mrsko otkucati dodatni "php" nakon "<?". Naravno mogli bismo da počnemo o malom teoretskom ubrzanju koje se javlja kao posledica parsiranja manje datoteke, ali ajde da ne zalazimo tamo, važi? Druga ti je standardni C-ovski ternarni operator ;) Postoje vremena kad ga treba koristiti, postoje vremena kad ne treba - obično se treba čuvati tzv "bočnih efekata" (side efects). |
Koliko znam, svi iole ozbiljni editori imaju code-completition pa kada ukucas <? odmah ti dodaje <?php i ?>. Bar je tako u homesite (doduse to sam ja namestio :)).
Ne, nikada na koristim shorthand tagove ni <? ni <?= ni slicno. |
Mnogo koristim i prvi i drugi način skraćivanja. Prvi način skraćivanja koristim samo u templateima (u ostalim fajlovima koristim klasični <?php ... ?>), a drugi koristim gde god mogu i gde je to razumno (meni deluje čitkije).
Kôd:
ini_set('short_open_tag', 1);Što se tiče XML i XHTML dokumenta jednostavno rešenje: Kôd:
<?= '<?xml version="1.0" encoding="UTF-8"?>' . "\n" ?>Ne volim mnogo koda. Deluje mi zabacano... Zato ću se najverovatnije u neko dogledno vreme (kad me puste trenutne obaveze) i prebaciti na Ruby. Sa 5 puta manje koda postižeš 5 puta više. Prilično dobra ponuda ;) |
A sta se desava kad imas microtime proveru izvresnja skripte
PHP kôd:
|
nixa, za početak pogledaj ovaj unos.
Po mom skromnom mišljenju micro-benchmarci nemaju puno smisla. Vremenski najskuplje stvari u web programiranju su IIRC upiti ka bazi, fajl sistemu i mrežnim resursima (ne obavezno tim redosledom). Najveće greške u optimizaciji (posle premature optimisation) nastaju kada neko odokativno počne da profiliše kod. Učili su me da je empirijski pokazano da se 5% koda izvršava 95% vremena. Tome služe profiling alati: 1. pomognu ti da nađeš uska grla, 2. pokažu ti realan dobitak u perfomansama nakon uklanjanja istih. Što se tiče primera koje si dao, na stranu što nije realan, pre bih izabrao prvi: čitljiviji je, ako ništa drugo. |
short_open_tag je po defaultu Off u 5.1.2... Debilno!
|
Pa tako i treba da bude, you lazy ... :)
|
Ono što meni ne ide u glavu je ZAŠTO tako mora da bude? Fino je što postoji opcija da se takvo ponašanje uključi / isključi ali zašto mora biti off po defaultu? Ja ne vidim razlog za to.
PS: Kratko otvaranje tagova koristim samo za brz echo. Umesto <?php echo $variable ?> kucam <?= $variable ?>. Za otvaranje i zatvaranje fajlova, blokova PHP koda itd koristim klasičan <?php ... ?> |
Pa menjaj default vrednost ako ti se ne dopada. Postavljeno je tako ... ako recimo praviš portabilan softver da se izbegne mogući problem.
ps - za brz echo koristim <?php echo $variable; ?> - a to će raditi na svakoj konfiguraciji. |
Najmanji problem dodati:
Kôd:
php_value short_open_tag On |
U cemu je razlika izmedju ova dva metoda? Eventualno scope tj .htaccess vrijedi za sve fajlove (ukoliko ne postoji drugi .htaccess) unutar direktorija, a ovaj ini_set vrijedi za samo php fajl u kome je napisano?
Kôd:
ini_set('short_open_tag', 1);Kôd:
php_value short_open_tag On.htaccess je OK metoda ako je dozvoljena, znaci ne mozes racunati da ces na sve i jednom hosting provajderu imati 'override' varijabli... recimo ljudi imaju problema sa paranoicnim Eunetom i safe mode-om. |
Paraonični my ass. To su likovi koji još uvek imaju register-globals aktivan.
|
I PHP u safe modu. I najsiromašniju PHP instalaciju koju sam video. I nemogućnost menjanja filesystem dozvola od strane korisnika.
|
short forma tagova je zgodna kad god se koristi php kao templejt jezik, upravo zato je razvijena, i ja je za to i koristim... sem u templejtima php tagove nikad ne pisem u istoj liniji sa kodom, ali kad se mesha php i hrml onda je skraceno pisanje citljivije .....u principu ne pravim skripte koje treba da rade na svakoj mogucoj konfiguraciji, ja ih sam postavljam na svoje servere, pa mogu i da namestim da sve radi ocekivano...ako ikada budem pravio neku public skriptu onda cu verovatno ispostovati punu formu pisanja, ali do tad nemam potrebe da se opterecujem hipotezama tog tipa, koristim najkracu i najcitljiviju varijantu... i radi...a sve sto radi ne treba dirati :)
|
Ista priča.
Ako budeš trebao da praviše nešto što treba da se vozi i na svim zamislivim instalacijama onda odradiš jedan search and replace i zameniš <?= sa <?php echo. To čak možeš da staviš kao task svog build alata i prestaneš da razmišljaš o tome. |
Čemu mješanje PHP i X/HTML codea kada postoji Smarty?
|
Postoji par jako dobrih razloga, ali da se ne ponavljam pogledaj ovu temu. Pogledaj pa razmisli još jednom da li, kome i kada ima smisla ;)
|
za zasto postoji {php}{/php} :P
|
A zašto izmišljati novi template jezik u jeziku koji je nastao kao template jezik, ima odlične template mogućnosti i snalazi se jako lepo unutar HTML fajlova? Zašto dodavati 200kb koda za nešto što može da se reši sa 4kb, a da zadrži istu funkcionalnost i pruži sve prednosti datog rešenja?
Poenta uopšte nije u ubacivanju PHPa u template, već korišćenju čistog PHPa za template. Smarty je vremenom stekao takav status da je bio must za svaki profesionalan razvoj. Tipa "Ti nisi pro ako ne koristiš Smarty" ili "Smarty je potreban da bi aplikacija bila dobra" i slične varijante. Međutim, ono što je istina je da je Smarty odličan za početnike jer ih PRISILJAVA da odvajaju template od svog koda i da ga većina nakon tog perioda koristi više po inerciji nego zato što ima stvarnu potrebu za tim. Kad malo uznapreduješ vidiš da je isto moguće postoći i bez 200kb koda, kompajliranja, nove sintakse i svih lepota što uz to sve idu ;) |
Ilija, brate rođeni, šta ti pričaš kewe ti... opet si čitao neke blogove? :)
|
Hehe. Ništa :) Samo sam hteo reći da je korišćenje Smartyja nepotrebno u većini slučajeva jer se potpuno ista stvar može postići sa mnogo lakšim klasama koje koriste PHP kao osnov za template.
|
ja koristim <? umesto <?php zasto ? ZATO STO ME MRZI DA OTKUCAM TRI KARAKTERA :)
|
Pa to je tek najmanji problem, ja imam podečeno da čim ukucam <? odmah doda php ?>, znaci odmah imam ceo blok <?php ?>. Ne mogu da shvatim da nekoga to mrzi, narocito posto ne mora da se kuca?
Napravio sam dvadesetak Auto completition (u hs) i recimo kada kucam foreach odmah dobijem PHP kôd:
Isto tako, cim ukucam <table (sa space iza) dobijem HTML kôd:
<table width="" cellpadding="2" cellspacing="0" border="0"> |
nije ni cudo sto neces da se odvojis od HS ni za zivu glavu :P
|
Templatei su mogućnost koju imaju svi ozbiljniji editori. U Zendu imam definisane template za PHPDoc, kostur klasa, funkcija, ciklusa (foreach, while...), generisanje gettera i settere, brzo pravljenje klasičnih kontrolera itd i stvarno ubrzavaju rad.
|
Ne znam sto bi nekoga mrzelo da sredjuje kod. Ja cak volim to da radim, vec dok pisem vodim racuna o formatiranju a ponekad, kada imam neki problem pa mi mozak prokuva ja se relaksiram tako sto uzmem da sredjujem sors, upisujem komentare i slicno...
|
Dear Ilija,
Ako praviš bilo kakvu PHP aplikaciju koja ima neki interface (a ne output) korištenje Smartya je zakon. Smarty dopušta ekstremno, ali ekstremno lako dodavanje novih funkcije, plugina i svega ostalog. Eto aj ti meni navedi zašto je smarty loš kada npr. programiraš neki mali forum, shout box ili šta god već želiš. (na stranu sve ono da je dizajnerima lakše i blablabal) |
Citat:
Iskreno,mislim da mnogi programeri koji koriste smarty grese u tome sto zele da odvoje HTML kod od PHP koda, a ne prezentacionu logiku od ostatka programa... Ako je ovo drugo cilj, onda Smarty i nije potreban (moze neko drugo resenje), te otpada pola stvari koje se navode kao prednosti smartija... |
zidoo, ne moraš me učiti šta se sve može sa Smartyjem i na koje se sve načine može proširiti. Koristio sam ga oko dve godine i radio sa naprednijim mogućnostima (resursima, funkcijama, blokovima, insertima...). Nisam koristio keširanje i pre/post filtere jer nisam ima potrebe za tim, ali znam kako rade i kad se koriste.
Takođe, već nešto manje od godinu dana radim bez njega i samo jednom se Smarty pokazao kao logičan izbor (dati korisniku da možde da edituje neke template kroz admin). Hvala što si probao da mi "otvoriš oči", ali znam obe strane priče... Jako dobro ;) |
Evo jedna interesanta prezentacija, gde je Rasmus Lerdorf sa par trikova uspeo da podigne performanse sa 17req/sec na 1100req/sec.
http://talks.php.net/show/zagreb2/8 |
Zanimljiva prezentacija, mada isti proces treba proći za svaku aplikaciju. Ovo je ipak prilično smešna skripta. Na primer, zamena include_once sa include u dosta slučajeva nije opcija jer je jako podložna greškama. Ali encodiranje, korišćenje trajnih konekcija itd su klasika za podzanje performansi skripti.
Btw, zna li neko dobar alat za profiling na Windowsu. Ja koristim XDebug + WinCacheGrind ali je to daleko od ozbiljnijih rešenja na Linuxu. |
Sta je taj CallGring koji crta one kul grafike, jel moze neko objasnjenje kako se to koristi ? Deluje mi skroz zanimljivo..
takodje mi se dopala upotreba APC za keshiranje promenjivih u sherovanoj memoriji, to nisam znao da php moze... to je inace fora koju mod_perl i mod_python mogu da rade direktno i mnogo je kul... @ilija: ja se na windowsu isto drzim xDebug, lako se instalira, a radi posao... Sta ti tacno fali od funkcionalnosti sa xDebug? |
Što se tiče deljene memorije nadam se da se zaključava pri svakom čitanju/upisu inače eto nama zabave do 4am :D
|
Citat:
|
a koji su to alati ?
|
| Vreme je GMT +2. Trenutno vreme je 01:28. |
Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.