Vlákno názorů k článku Jan Minárik: S Rails vyvíjíme efektivněji od Jan jam - zajímalo by mne srovnání v rychlosti oproti webovým...
-
Zkousel jsem testovat rychlost ruby proti PHP a v ramci mych testu bylo asi sestkrat rychlejsi. Ale pozor, to neni vubec smerodatne, jednalo se jen o velmi omezeny okruh testu, takze to o nicem nevypovida a o tom, jak rychle to bezi na serveru teprve ne. Ale nicmene nemyslim si, ze by problem Ruby byla rychost, to ani ne, spise pamet. Klasicke reseni, tj. mongrelovy cluster si vyzere skutecne hodne. Ale na druhou stranu to se kompenzuje vetsimy zisky za aplikace, ktere vyvijite vyrazne rychlejsi. -
anonymníKrome toho, ze interpret ruby je jeden z nejpomalejsich (orientacne viz. napr. http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all), tak RoR rychlosti zrovna dvakrat neprida. Jako hlavni problem vidim jejich ActiveRecord, ktery si s optimalizaci zrovna hlavu nedela (ovsem neznam nejnovejsi verzi), do databaze posila obrovske mnozstvi dotazu, kde nejsou potreba. Takze v kritickych castich jsem byl nucen se vykaslat na pekne, ciste a kratke zapisy v Ruby a nahradit je stejne osklivymi a slozitymi lec rychlymi SQL prikazy.. :( Pokud je potreba neco pocitat mimo databazi, tedy v pripadech, kdy jde o hruby vypocetni vykon Ruby, tak je rychlost interpretu take znatelna.. Jinak s vetsinou "PR reci", ktere se tykaji efektivity programovani (koneckoncu i zabavy pri psani;), vicemene souhlasim a verim, ze se RoR bude dal s postupem jeho vyvoje zefektivnovat a prichodem Ruby 2.0 se situace dal zlepsi..
-
kb (neregistrovaný)Ja ale nechapu to neustale srovnavani s PHP. I na tech videich co byly v tom nejakem blogu hned po konferenci. Srovnavate framework a jazyk, coz je tak trochu blbost. Pokud zacnete psat aplikace from scratch v ruby i v php bude s tim spousta prace. Srovnavejte spise Symfony a RoR. To uz by bylo porovnatelne. Trochu symfony znam a myslim, ze s nim by se dali taky rychle a efektivne vyvyjet aplikace stejne jako v RoR (ale nechci zakladat flame, jen nazor). Navic kdyz se dva hadaji treti se smeje :) (Python?).
P.S. po te konferenci se zacinaji objevovat nehorazne tendecni clanky opevujici RoR. Tim nerikam, ze jsou spatne, samotneho me laka je vyzkouset. Jen dojem. -
Hmm, já mám zase z PHP pocit, že bude pomalejší, protože je "one-shot", při každém požadavku musí zpracovat skoro všechno znovu. Oproti tomu dlouhoběžící proces (nějaký aplikační server) může výrazně těžit z toho, že si bude data uchovávat v paměti. "Tvrdá čísla" samozřejmě nemám.
Problém je v tom, že aby člověk získal "tvrdá čísla" musí mít nějakou složitější úlohu a většinou nemá čas ji napsat ve dvou jazycích. Syntetické testy je možné nastavit tak, aby vyhrával libovolný z jazyků.
PS: V Ruby nepíšu, srovnávám PHP a Python. -
PHP se da spustit jako FastCGI. Proto se pak vsechno nemusi zpracovavat znovu ale zavola se jen program v pameti. Dalsi vyhodou FastCGI je i to, ze kdyz si program navaze spojeni na DB, tak si ho ten program uchova tak dlouho, jak je to nastavene v DB serveru. Ono navazovani spojeni s DB je take dosti casove narocne a zatezuje to navic jak aplikacni tak DB server. Proto doporucuji u velkych projektu pouzivat FastCGI technologii. FastCGI ma podporu nejen v PHP, ale i v Perlu, Pythonu a dalsich jazycich.
-
Ivan (neregistrovaný)Ono moc reseni neexistuje. PHP, Perl i Python maji problem v tom, ze jsou postavene na
knihovnach napsanych C(C++), takze i kdyby nakrasne byly jejich interpretry multivlaknove,
tak alesom jedna knihovna na kterou maji binding nebude thread-safe. I kdyby i bylo vsechno thread-safe tak budou knihovny obsahovat memory leaky. Multivlaknovost PHP je jen chimera. Threaded worker Apache2 je uz hodne dlouho unstable a v kombinaci s PHP asi nikdy fungovat nebude. Akoliv jsem byl hodne dlouho odpurce JAVY, tak jsem musel uznat, ze v kombinaci s DB Oracle jsou aplikacni servery postavene na JAVE mnohem vykonejsi nez cokoliv postavene na Apache. Pokud totiz otevirate a zavirate 200 DB session za sekundu tak je uplne jedno
jestli mate aplikaci napsanou v JAVE nebo z assembleru. -
Rejpal (neregistrovaný)Hmm, ale nakonec je všechno napsané v Cčku, ve kterém mohou být memory leaky. V JITu můžou být chyby. Když mohou být leaky nebo chyby v PHP nebo Apachi, proč by nemohly být v Javě? Nebo v těch mamutích aplikařních kontejnerech? Nebude fígl v tom, že když je něco hodně používané (Java, Apache, PHP), budou v tom ty chyby vychytané? ;-)
Věta "i kdyby nakrasne byly jejich interpretry multivlaknove, tak alesom jedna knihovna na kterou maji binding nebude thread-safe" je mírný úlet, protože to zcela jistě nutné není - nebo snad překročíte stín vlastní mlčenlivosti a prozradíte nám, kterážeto knihovna je naprosto nevyhnutelná a přitom thread-unsafe?
