Speed ​​Srovnání - Procesní vs. OO v interpretovaných jazycích

hlasů
17

V interpretovaných programovacích jazyků, jako je PHP a JavaScript, jaké jsou dopady jít s přístupem objektově orientovaného průběhu procesního přístupu?

Konkrétně to, co jsem hledal je kontrolní seznam věcí, které je třeba při vytváření webových aplikací a výběr mezi procesním a objektově orientovaných přístupů k optimalizaci nejen rychlost, ale také udržovatelnost. Citované výzkumné a zkušební případy by mohla být užitečná i pokud víte o nějaké články prozkoumávat to dál.

Sečteno a podtrženo: Jak velký (pokud vůbec) je výkon hit opravdu, když jde s pozorovatelem versus procesní v interpretovaný jazyk?

Položena 06/08/2008 v 04:34
zdroj uživatelem
V jiných jazycích...                            


7 odpovědí

hlasů
17

Možná jsem blázen, ale starat o rychlosti v případech, jako je tento pomocí interpretační jazyk je jako snažit se přijít na to, jakou barvu malovat kůlny. Pojďme dostat ani na myšlenku, že tento druh optimalizace je zcela pre-zralé.

trefil hřebík na hlavičku, když jste řekl, ‚udržovatelnost‘. Já bych zvolit přístup, který je nejproduktivnější a nejvíce udržovatelné. Pokud potřebujete zrychlit později se nebude pocházet z přepínání mezi procesní proti objektově orientovaného kódování vzory uvnitř interpretovaný jazyk.

Odpovězeno 06/08/2008 v 04:36
zdroj uživatelem

hlasů
10

Bohužel jsem udělal mé testy příliš. Udělal jsem zkušební rychlosti, a je to asi stejné, ale při testování pro využití paměti získání memory_get_usage () v PHP, viděl jsem v naprosté většině případů větší počet na straně OOP.

116,576 bajtů pro OOP na 18,856 bajtů pro procesní. Vím, že „Hardware je levný“, ale no tak! Nárůst 1,000% v provozu? Je nám líto, že to není optimální. A má tolik uživatelů bít své webové stránky najednou, jsem si jist, vaše RAM by jen vypálit, nebo dojdou. Mýlím se?

Odpovězeno 22/07/2011 v 22:28
zdroj uživatelem

hlasů
5

Sečteno a podtrženo: ne, protože režijní interpretace přemůže režii metody dispečinku.

Odpovězeno 06/08/2008 v 04:35
zdroj uživatelem

hlasů
2

Pokud používáte interpretovaný jazyk, je tento rozdíl irelevantní. Neměli byste používat interpretovaný jazyk, pokud výkon je problém. Oba vystoupí zhruba stejný.

Odpovězeno 06/08/2008 v 04:49
zdroj uživatelem

hlasů
1

Podle mých zkušeností, bude místo při velkém zatížení je zapadlý a přestane reagovat mnohem snadněji s OOP kódem než procedurální. Důvodem je snadné pochopit.

OOP vyžaduje mnohem více přidělení paměti (malloc) a mnohem více operací ke spuštění v paměti než procedurální kód. To vyžaduje mnohem více času procesoru k plnění svých úkolů. Je to v podstatě ‚nad hlavou‘, omotal kolem procedurální kód, čímž se CPU zátěž jej spustit, a to zejména při provádění operace databáze.

Mnoho programátorů, jako je pohodlí OOP, vytváří malé černé krabičky schované za jednoduché rozhraní. Nicméně, jsem byla věnována také oživit stránky, které užívali navždy reagovat při velkém zatížení uživatele. Odstraňováním OOP a nahradit ji s jednoduchými funkcemi procedurálních udělalo obrovský rozdíl.

Pokud nechcete čekat, aby vaše stránky být velmi zaneprázdněn, a to všemi prostředky používat OOP. Pokud jste budování high-dopravní systém, budete chtít, aby se svlékli každý CPU cyklus od zpracování a každý byte z výstupu, který můžete.

Odpovězeno 22/03/2015 v 19:31
zdroj uživatelem

hlasů
1

Váš výkon bude charakterizován provádění, nikoli jazyka. Dalo by se použít nejpomalejší jazyk a to by mohlo škálovat být největší web na světě tak dlouho, jak navrhnout to v měřítku.

Jen si vzpomeňte na první pravidlo optimiztion.

Ne.

:)

Odpovězeno 22/09/2008 v 19:18
zdroj uživatelem

hlasů
0

Já jsem vlastně udělal malý test, jako je to v pythonu na internetových stránkách jsem byla zachována a bylo zjištěno, že jsou téměř ekvivalentní rychlosti s tím, že procesní přístup vyhrávat něco jako deset tisícin sekundy, ale že OO kód byl tak významně čistič jsem nepokračoval výkon déle než jednu iteraci.

Takže ve skutečnosti, že nezáleží na tom (dle mých zkušeností tak jako tak).

Odpovězeno 26/08/2008 v 21:01
zdroj uživatelem

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more