Dotaz: bufferování vs. okamžitý výpis [bylo: Návrh řešení]

[Prosík]

Chtěl bych se zeptat ještě na jednu věc, co je lepší, veškerý zpracovaný kód okamžitě vypsat na screen nebo to můžu ukládat všechno do proměnných a pak vypsat všechno jedním echem. Má to vliv na paměť, výkon nebo něco jiného? Děkuji

Odpovědi

[Josef Kufner]

Úvod do architektury MVC

Výkon (paměť a tak) je až na druhém místě. Na prvním je udržovatelnost a rozšiřitelnost aplikace.

[Prosík]

Čili jinými slovy ...... ?

[LangPa]

Pro příště by se vyplatilo napsat že se jedná o PHP.

...Jinými slovy - čas kodéra je dražší než HW zdroje, takže v první řade záleží na čitelnosti, čistotě, znovupoužitelnosti a udržitelnosti kódu.

Pro udržení štábní kultury se hodí používat nějaký framework, je jich hodně: Zend, Nette, Symfony, ...

Pokud se generuje obsah, je dobré používat nějaký šablonovací nástroj (Nette+Latte, Smarty, ...), který vygeneruje výsledný HTML kód.

[Kit]

Podle mých zkušeností je čistě napsaný kód často efektivnější, než rádoby efektivní, ale komplikovaný. Kompilátory obvykle v sobě mají optimalizátory, které čistě napsaný kód zvládají lépe.

Vzhledem k tomu, že při výpočtu ještě nevím, jaké hlavičky budu prohlížeči posílat, výstup generuji jedním echem. Ovšem nedělám to kvůli efektivitě, ale kvůli jednotnosti a přehlednosti generujících metod. Také kvůli obsluze některých výjimek.

[Mr.S1lent.cz]

Vzdy se vyplati posilat konecny vystup az pri konci behu scriptu a to z jednoho prosteho duvodu - jestlize nastane chyba pri behu scriptu, tezko ji pak v mezivypise schovas pod custom 500 ci provedes redirect... Vysledkem by totiz byl v pulce useknuty layout )))

Navic se bavime o opravdu zanedbatelnem casovem intervalu. Vic clovek usetri dobrym navrhem db a cachovanim

[DK]

jeste bych dodal, ze pokud kod pisete citelne, je lepsi psat bez frameworku (on ten vykon pri vysoke zatezi je taky nekde jinde pak), co se tyce buffovani / tisknuti najednou, zalezi to na pouziti (nekdy je treba nutne tisknout vsechno najednou, nekdy ne), ale z hlediska efektivity je to pomerne jedno (ja preferuju vetsinou okamzite tisknuti, pokud uz nekdy resim tisknuti najednou, resim to vetsinou pres OB a ne pres jednu promennou -> ale zalezi na situaci a zvyklostech programatora)

[Mr.S1lent.cz]

Nedokazu si predstavit, ze bych vetsi aplikace (ale i ty male) musel psat v "cistem PHPku" a znovuvymyslet funkcnost implementovanou ve vetsine (vsech) frameworcich - routery, loadery, form generatory/validatory, db connectory a layery, sablonovaci systemy, MVC model...

Bud nepises velke komercni projekty, anebo jsi masochista Nehlede na tom, ze rezie frameworku neni vetsinou skoro vubec znat a stroj stejne nejvic zabiji db queries

[Kit]

Když se používá líná databáze a framework, který neumí zformulovat trochu složitější SQL dotaz...

Velké projekty nepíšu, to je fakt, ale spoustu potřebných funkcí už PHP v sobě má. Včetně šablonovacích systémů. MVC se v PHP dá vyrobit na několika málo řádcích, na to není potřebný framework.

[Mr.S1lent.cz]

U frameworku si clovek muze vybrat, jakou databazovou vrstvu pouzije. Kazdopadne nevim, co si mam pod pojmem "neumi fromulovat trochu slozitejsi SQL dotaz" predstavit. Pokud nepouzivame nejake ORM (v PHP napr Doctrine 2), pak si stejne SQL piseme v modelech sami rucne, anebo pouzijeme nejake jednoduche prime fluent interface, kde jen o skladani stringu Coz je jen nejaky realloc a memmove A pokud pouzivame ORM, i presto se neni ceho bat - preci jen takove nastroje nepisi juniori

A pak je druha otazka - proc bych to mel vyrabet, kdyz uz je to vyrobene, odzkousene a ti padem bezpecne, stabilni a umi to presne to, co ja potrebuji? Parada, ty napises sablonovaci system na 20 radku a co z toho, nic to nebude umet a tebe to bude stvat a postupne tam budes pridavat fukcnost a dostanes se na uroven bezneho frameworku.

Ja osobne nemam potrebovu vymyslet kolo, ja se na nem pouze vezu

[Kit]

Proč bych měl psát šablonovací systém, když už je přímo součástí PHP? Stačí ho jen zavolat, dát mu šablonu a data. To zabere asi 6 řádek. Navíc je ten šablonovací systém Turing-kompletní, na omezení tedy nenarazím. Je to vyrobené, odzkoušené a bezpečné.

SQL si v modelu také píšu ručně. SQL mi přijde přehlednější a vhodnější, než se učit další metajazyk nějakého ORM.

[Ash]

Hezky řečeno.

[DK]

databaze - PDO
zbytek - vlastni

velke aplikace typu desktopovych aplikaci fakt nedelam, ale aplikace ktere denne navstevuji minimalne stovky tisic lidi delam (a v cistem php je to rychlejsi :) )

[Josef Kufner]

A formuláře?

[Mr.S1lent.cz]

IMHO je jedno, jestli generovani kodu trva 0.045ms nebo 0.032ms, kdyz se to pak uploaduje 10ms visitorovi, ale jde predevsim o bezpecnost, rychlost vyvoje a prehlednost. Kdyz vyvijim aplikaci, nechce se mi resit milion low level veci, ktere by mohl obstarat framework a soustredim se vylozene na vyvoj aplikace. Ten tvuj sablonovaci system na 6 radku asi nebude umet generovat linky synchronizovane s routery a dalsich x veci, ktere je treba, ze? Navic soucasti PHP urcite nejsou local-side form validatory nebo treba nejake debug nastroje (var_dump je v urcitych pripadech docela k nicemu). A to nepocitam routery a loadery. Pokud ti nesedi "velke" frameworky, neni problem se podivat po nejakych light.

A pokud se honis opravdu tak moc po vykonu, pak zapomen PHP a zacni se ucit Python, pripadne C++ a web kit k tomu

[DK]

ty musis mit vzdycky pravdu ze? :)
ono u generovani kodu pri par stovkach UIP denne, je rozdil casu naprosto nanic, ale kdyz ti na stranku lezou 4000 lidi ve stejnou dobu, je to neco jineho

kdybych se honil za vykonem a bylo by to na me, nedelal bych to na php, ale pouzil bych nektery z jinych jazyku, ktere umim (napriklad python, nebo java)
co se tyce "linku synchronizovanych s routerem" -> vubec netusim, co tim mas na mysli (takhle to vypada, ze si jenom tahas hovadiny z kapsy, abys vypadal krutoprisne :) ), ber to cele na obecny priklad, ne konkretni veci, ktere jsi kdy delal,pak taky muzu tvrdit veci, o ktere jsi pravdepodobne ani nikdy nezavadil a aplikovat to na celou mnozinu prikladu

jinak pokud neumis udelat validator formularu bez frameworku, jdi si radsi delat weby pres webnode (to abych si rypnul )

a propos, ja netvrdim, ze frameworky jsou spatne, to jsem nikdy nerekl... akorat, pokud v tom php umis dobre a nepises prasacky kod, je lepsi VELKE (tj hodne navstevovane) projekty psat nekdy bez frameworku

[Mr.S1lent.cz]

Nemusim mit vzdycky pravdu, jen mi to celkem neprijemne bije do oci, co tu ctu. Pokud mi na stranku leze 4000 lidi, pak mam vse v cache, jak to ma vetsina frekventovanych webovych sluzeb. A i presto, pokud se zenu za enormnim vykonem, pak se koukam po nejakem Pythonu a C++, jak jsem napsal vyse.

Jiste, ze validatory umim, napsal jsem par jQuery pluginu, jen mam rad svuj cas. Staci mi nainstancovat jednu LiveForm tridu, pridat form element pres jednu metodu a mam vystarano, zatimco ty se budes sudlit s nejakou validaci, sem tam udelas preklep a ztratis par cennych minut. To same v pripade redirectu nebo generovani linku. Staci mi zadat pouze nazev Controleru a akce (pripadne nazev routy u nekterych frameworku) a o vse se framework postara sam.

Mozna ti to pripada jako 10k radku kodu k nicemu, fajn. Ja treba pouzivam Nette/Doctrine2 a Zend/Doctrine2 (v PHP, kde mi jde predevsim o rychlost vyvoje). Za 2 minuty si vytvorim databazovou entitu, kterou prozenu pres macra v IDEcku, vyuziju dedicnosti Controleru a za dalsich 5 minut mam v administraci akci na vypis a editaci dane polozky i s validaci a vsim, co k tomu patri. Ty uz mozna budes nekde u 3. SQL dotazu, ale hlavne, ze nebudes mit zbytecnych 10 radku.

Pokud se tim nezivis, pak si to pras, jak chces. Pokud se tim zivis, jako ja, pak bych rekl, ze se na projekt o dost vic nadres, jak ja. Hlavni je, ze zakladem bude 100 radku

Ani nechci vedet, jak takove vetsi projekty debugujes

[Šangala]

Aby to nebylo jednostranné. „Cizí“ framework super, ale pak to klade docela vysoké nároky na udržování aplikace, bo tam se s něčím nepočítalo, tam se udělal nějaký workaround kvůli nějakému prohlížeči a pod.
Pak se nasadí nová verze, protože se opravuje spousta chyb ve Frameworku, a pak se ladí zkouší a někdy to zjistí až zákazník.
Sem tam se směju kamarádovi, co řeší více problémy frameworků, než vlastní kód, a i když chápu že je to z určitého pohledu výhodnější framework, tak mu často říkám: „Vidíš kdybyste si těch pár blbostí napsali sami, máte pokoj a opravdu jen sem tam vyřešíte věc, ve které se vyznáte a ne takové blbostí, kde po týdnu zkoumání zjistíte, že ten kdo psal se špatně vyspal nebo řeší - špatně - věc, kterou vy máte zmáklou už dávno. Prostě jak vždycky snad rychlejší vývoj ale za to pomalejší a drahé udržování.“
No pak samozřejmě taky častý jev, přetížený server obecnýma blbostma z Frameworku, které mají být specifické tj. obvyklé porušení „neoptimalizuj pozdě“ a přehnané dodržení „neoptimalizuj brzo“.

[Kit]

Jistě, některé frameworky jsou povedené a užitečné. Například jsem si oblíbil jQuery. Ovšem když na některých stránkách vidím kombinaci 5 frameworků jen proto, že někdo potřebuje z každého jen jednu funkci, tak je to prostě moc.

Ovšem PHP obsahuje spoustu modulů, které mají charakter frameworku. Stačí je jen použít.

[Ash]

To pojídači koláčků nevysvětlíš :D

[Kit]

Ty jsi to asi nepochopil. Když jsem napsal, že ten interní šablonovací systém PHP je Turing-kompletní, tak to znamená, že umí vše, co lze naprogramovat. A rozhodně to není low level.

A výkon? Vzhledem k tomu, že tyto knihovny jsou AFAIK napsány v C nebo C++ (přinejhorším v kompilovaném PHP), tak ho nemusím řešit. Frameworky dodávané s PHP mi prostě stačí.

[Kit]

Ještě bych k tomu dodal, že raději si napíšu 100 řádek vlastního frameworku, než abych includoval 10k řádek cizího kódu, který dělá spoustu činností, které nepotřebuji a ze kterého je mi na blití, protože to psalo prase.

[Josef Kufner]

Framework dokáže ušetŕit hodné práce, ale je fakt, že některé jsou zbytečně nakynuté a líné. Stačí však sáhnout po něčem lehčím. Nezaměňovat však "je to rychlé" s "nic to neumí"!

[Mr.S1lent.cz]

O tu praci jde predevsim. Rezie kodu je ve srovnani s rezii prace nesrovnatelne nizsi. Prakticky neznam zadny vetsi projekt, ktery by si nekdo lajzl bez frameworku a ani nevim, jestli je to vubec do nejake miry mozne, aby mel clovek rozsahly kod patricne udrzovany a dobre zdokumentovany a predevsim prehledny.

[Kit]

Ano, je to možné. Stačí umět programovat.

[Mr.S1lent.cz]

No, to bohuzel nestaci. S frameworkem je prace x-krat efektivnejsi Pokud se tim zivis, chces odvezt co nejlepsi praci za co nejkratsi cas. Nejradsi bych weby psal v Cecku, ale protoze bych jeden psal pul roku misto jednoho tydne, tak je radsi pisu v php ci pythonu a s pouzitelnym, odzkousenym frameworkem ve stable verzi

Pouzivat framework neni nic nebezneho. V zadne firme se vyvojari bez frameworku neobejdou, at je to treba google, yahoo nebo i cesky seznam, kde si kluci prosadili pythonove django a zrovna v takovych firmach bych rekl, ze vyvojari programovat umi - to se ovsem prici s tvoji teorii, ze ano

A pokud se nekomu ani jeden framework z nejakeho duvod nelibi, napise si vlastni nastroj, ktery mu urychli vyvoj a zprehledni kod. Ja osobne na vymysleni kola cas nemam, proto rad pouziju overene reseni, ktere je pod drobnohledem nekolika mnoho vyvojaru a uzivatelu a diky tomu je vyskyt chyb minimalizovan vice, nez kdybych si to jako domaci pgral napsal doma sam...

[Kit]

A co frameworky dodávané s PHP? Pokud chceš odvést kvalitní práci, musíš je znát. Bohužel běžné frameworky se jim úspěšně vyhýbají a šmudlí to po svém.

Psát weby v Céčku je blbost, to je snad jasné. Určitá úroveň abstrakce je nutná. Proto vznikly jazyky PHP, Python, Ruby, Lua a další, které vývoj webu značně urychlují.

[Mr.S1lent.cz]

Frameworky dodavane s PHP? Myslis vlastni funkce a metody jazyka? Porad moc low level. Vyvojar aplikace by se mel venovat ciste jen logice aplikace a ne zbytecnemu programovani okolo, ktere je porad stejne a jenom zdrzuje. Jasne, muzes si to napsat sam, ale postupem casu zjistis, ze tam ti chybi funkcnost, tam a tam a po 10ti letech zjistis, ze vlastne jsi nekde na urovni light frameworku, ovsem overenym jen jednim parem oci a tim padem potencialne zabugovanym. Ja proste tolik casu nemam, abych se rozepisoval jak spisovatelka pri kazdem webu - to uz jsem si tak trochu pripadal, kdyz jsem pouzival Zend Framework. A neni to jenom u webu, v C++ hojne vyuzivam Boost library atd. Tyto nastroje maji za cil pomahat a opravdu pomahaji predevsim v rychlosti a bezpecnosti aplikace.

[Kit]

Ne. Mám na mysli plnohodnotný šablonovací systém, který v PHP je. Zřejmě ho vůbec neznáš. A vůbec není low level, ale naopak má vysokou úroveň abstrakce. Používá se i v Javě, Pythonu a dalších jazycích. Šablony jsou přenositelné, jazyk je velmi dobře zdokumentován.

[Mr.S1lent.cz]

O zadnem takovem bohuzel nevim, ale klidne muzes byt konkretnejsi, protoze sablonovaci system patri mezi caste otazky na diskuznich forech a na zadny takovy, ktery ma podporu primo v PHP ci jeho extensions jsem zatim nenarazil (coz je divne)

[Kit]

XSLT.

[Šangala]

Psát weby v Céčku je blbost,

Ehm, je to sice C++, je to sice Framework, ale zkus si wt, třeba tě překvapí jak málo zdrojů je třeba, jak rychle to funguje, a i docela rychle se to používá (Zatím jsem to sice, na nic většího nepoužil, ale po úspěšných začátcích to na určité věci hodnotím slovem „super“ - zvláště když je třeba více počítání v pozadí).

[Kit]

C++ je trochu jiný level než C. Nedělám v něm, ale věřím, že by se v něm dala udělat velmi slušná webová aplikace. Dokonce by ani nebyl nutný Apache, protože v knihovnách je podpora HTTP. Takový dietní server by mohl být velmi výkonný. Jenže kdo by se s tím ladil, že?

[Josef Kufner]

Ono nejde o to, aby bylo jedno echo na konci, ale o to, aby ty echa byly pohromadě a nebyly namíchány s logikou (ostatním kódem). Navíc pokud je echo jen jedno, tak nelze vypsat velké objemy dat (desítky MB). Output buffering by při slušném návrhu aplikace neměl být potřeba (i když je to jinak užitečná věc), rozhodně je však rychlejší než si to syslit do proměnné.

[DK]

ono OB je treba, pokud se vytvari treba takova cache, jinak je pomerne zbytecny :)