Adresarova struktura Feature-Re-Request (#2)

David Grudl napsal(a):

Zaujalo mě, kolik lidí tu kombinuje různé loadery pro různé knihovny. Vždyť RobotLoader je právě lékem na nutnost kombinovat více loaderů.

Pokud chceš načítat RobotLoaderem něco většího (třeba Doctrine nebo něco Symfony), tak to znamená příšerné zpomalení.

David Grudl napsal(a):

ad PSR-0: to je jeden z důvodů, proč má třeba Zend Framework (a zejména Magento) obrovské problémy s výkonností.

V čem spočívá ono zpomalení? Vždyť díky dodržování standardu loader přesně ví kam pro danou třídu sáhnout a nepotřebuje nic načítat.

Jinak k tématu: nemálokrát jsem také narazil na „zrádnou“ adresářovou strukturu Nette a myslím, že je dobrý nápad, aby názvy souborů/složek korespondovali s názvy namespace/tříd. (proti výjimce u složky common nic nemám). Nicméně pokud existuje dobrý důvod (který zatím neznám), proč tomu tak není, tak má David pravdu, že slepé dodržování standardu neni zrovna to pravé ořechové.

Editoval Elijen (3. 1. 2012 1:50)

hrach napsal(a):

Přečti si k tomu ty diskuze, at se tady porad neresi to samy.

Cetl jsem toto a vlakno linkovane v uvodnim postu + cast prispevku na root.cz ale prilis padnych argumentu nezaznelo (spise jen zbytecny flame).

• cim vic souboru nactes → pomalejsi aplikace;
• psr 0 → vice souboru = kazda vyjimka vlastni soubor, atp.
• nette v 95 % pripadu psr 0 dodrzuje, vyjimky jsou vyjimky a common.

Adresarova struktura Nette je tak trochu citit premature optimization. Nemyslim si, ze by vycleneni vyjimek do zvlastnich souboru nejak rapidne zpomalilo aplikaci. Precijen vyjimek se v zivotnim cyklu aplikace zas tolik nezavola. (od toho se jmenujou „vyjimky“ :-))

Co se tyce ostatnich trid: Chapu, ze nektere tridy nemohou existovat bez jinych a jsou natolik pribuzne, ze ma opravdu smysl je dat do jednoho souboru. Jak casto se toto ale stava? Natolik, ze by striktni dodrzovani PSR-0 meritelne zpomalilo aplikaci? Nemyslim si. Navic nemela by pripadne zpomaleni aplikace spise resit nejaka forma cachovani?

Pak zbyva slozka common, pro kterou by asi bylo idelani vytvorit namespace Nette\Common a slozku prejmenovat na „Common“, coz by ale byl BC break :-/

Editoval Elijen (3. 1. 2012 13:34)

Co se týče výkonnosti, tak osobně bych uvítal něco mezi normální a minifikovanou verzi. Protože jsou soubory, které potřebuji (téměř) vždy jako třeba Debugger, Presenter, Application… ale pak je i spousta souborů, které se používají občas a je zbytečné je načítat pokaždé, k čemuž při použit minifikované verze pochopitelně dochází.

Přesně! Minified Nette mi nevycházelo moc dobře, protože sice je to 1 soubor, ale zase to znamená, že se musí nevyhnutelně přechroustat celé Nette, takže je to nakonec výrazně nejpomalejší řešení (plus ta RAM).

Taky bych bral něco, kde by se načítaly bloky s částmi, které budou nejpravděpodobněji použity/použity dohromady … o level výš by asi byla inspirace NotORM cachováním (select ??? from) – že by se vytvářela jakási definice toho, co se v dané aplikaci nejvíc pouští dohromady a podle tohodle předpisu by se zkonstruovala takovéto optimalizované cache bloky

Ten kdo ma deploy, minifikaci neřeší, používa normální. Na disk to nemá žádné zpomalení, všechny ty skripty časo spoustěne skripty jsou v diskové cachi automaticky.

Já jsem to měřil a jako nejrychlejší mi jednoznačně vyšel PHAR vytvořený z minifikované verze Nette při použití APC ;)

Na obyčejném počítači jsem snadbox dostal asi na 4ms.

Editoval pekelnik (4. 1. 2012 5:27)

Při použití opcode cache (například APC) je minifikovaná verze řádově rychlejší než plná. Bez cache může být teoreticky pomalejší.

David Grudl napsal(a):

Ano, kdyby to tak bylo kvůli rychlosti, šlo by o premature optimization, nicméně důvodem není rychlost, ale přehlednost a pohodlí. (Tj. jsme v naprostém sporu ;-)

Bohuzel to tak neprijde vsem. Chapu, ze je tezke se zavdecit kazdemu, ale prave od toho (mimo jine) jsou tu standardy.

Jsem přesvědčen, že rozdělení Nette\common\exceptions.php do 15 souborů způsobí jen a pouze horší orientaci v adresáři.

Proc nemit pro vyjimky vlastni namespace Nette\Exceptions a dat je do vlastniho adresare?

Jsem přesvědčen, že přejmenování Nette\Object na Nette\Common\Object jen a pouze ztíží život programátorům (a teď nemám na mysli otázku kompatibility).

V cem ono ztizeni zivota zpociva?

Tak premyslim, zda ma na toto tema vubec cenu diskutovat. Jednak tu hraji velkou roli osobni preference kazdeho jednotlivce a druhak pouhe presunuti/prejmenovani souboru/adresaru asi nic moc nevyresi, bylo by treba upravit namespaces a to by vedlo ke spouste BC breakum. (a nasranym uzivatelum)

Editoval Elijen (4. 1. 2012 10:55)

David Grudl napsal(a):

BTW, neštve vás, že jsem v API rozdělil zvlášť výjimky, rozhraní a ostatní třídy? Dokážete se v tom teď zorientovat? ;-)

To je běžné chování Apigenu 2.x ne? Mě se v tom lépe orientuje… :-)

Edit: jen by se v https://api.nette.org mohli zapnout i @internal metody a třídy. Celkem často narážím na to že se k nim prostě nedoklikám. :-(

V Apigenu 2.x mají internal třídy a metody vlastní class (v defaultním template je nastaven s méně výraznýmy barvamy aby se dal lehce přehlédnout).

Řeším to steně ovšem pokud s někým řeším něco třeba na Jabber-roomu a potřebuju odkázat tak mám problém.

nepřejmenovat. s velkým N by se to pletlo s jmennými prostory a s malým by to nebylo cool