Verze z 14. 4. 2009, 16:01 editovat Jan Loufek (diskuse \| příspěvky) 8 editací Bez shrnutí editace ← Přejít na předchozí porovnání		Verze z 14. 4. 2009, 16:10 editovat zrušit editaci Jan Loufek (diskuse \| příspěvky) 8 editací Bez shrnutí editace Přejít na další porovnání →
Řádek 18: Interpretovaný kód je pomalejší než běh kompilovaného kódu, protože interpret musí analyzovat každý program v každém okamžiku kdy je spuštěn a pak provést požadovanou akci, vzhledem k tomu, že kompilovaný kód právě provádí akci ve stanovené souvislosti stanovené na základě kompilace. Tato run-time analýza je známá jako "interpretační režie". Přístup k proměnné je také pomalejší, protože v interpretu musí být provedeno mapování identifikátorů na paměťová místa opakovaně na run-time a ne na kompilaci. Zde jsou různé kompromisy mezi rychlostí vývoje, při použití interpreta a rychlosti provedení programu při použití kompilátoru. Některé systémy (např. některé [[Lisp\|LISP]]) umožňují interpretovaný a kompilovaný kód volat navzájem a sdílet proměnné. To znamená, že jednou je program testován a odladěn pod interpretem lze jej kompilovat a tím využívat rychlejšího provedení ~~progamu~~programu , zatímco jiné programy jsou vyvíjeny. Mnohé interprety nebudou vykonávat zdrojový kód, jak je napsán, ale převedou si jej do nějaké větší kompaktní vnitřní formy. Například některé interprety [[BASIC\|BASICu]] nahradí [[ Klíčové slovo\|Klíčová slova]] s jedno bytovým znakem, které lze použít k nalezení instrukce ve skoku v tabulce. Interpret, může používat stejný [[Lexikální analýza\|lexikální]] a [[Syntaktická analýza\|syntaktický]] analyzátor jako kompilátor a pak interpretovat výsledný abstraktní syntaktický strom. == Interpret Bytekódu == Řádek 25: == Interpret abstraktního syntaktického stromu == Mimo možnosti interpretace a kompilace, je jiný přístup a to ~~transformovace~~transformace zdrojového kódu do optimálního abstraktního syntaktického stromu (Abstract Syntax Tree - AST), a následné řízení výkonu programu podle této struktury. V tomto přístupu je třeba analyzovat každou větu pouze jednou. Hlavní výhodu oproti bytekód interpretaci je, že AST udržuje globální program, strukturu a vztahy mezi instrukcemi (která se ztratila v bytekód reprezentaci), a poskytuje více kompaktní reprezentaci. Proto byl navržen AST jako lepší průběžný formát pro Just-in-time kompilátory než bytekód. Rovněž umožňuje provádět lepší analýzu během běhu. Na [[Java_(programovací_jazyk)\|Java]] interpretu založeném na AST bylo dokázáno, že je rychlejší než obdobné interprety bytekódu, díky této silnější optimalizaci dovoluje mít kompletní strukturu programu, která je k dispozici v průběhu spuštění. Řádek 33: Další možností, která využívá výhod interpretů, byte-kód interpretů a kompilací je [[JIT\|just-in-time]] kompilace (nebo JIT = právě v čas), což je technika, ve které je meziprodukt reprezentace programu kompilován do nativního [[Strojový_kód\|strojového kódu]] za běhu. To vyrovnává účinnost běhu nativního kódu, na nároky na čas spuštění a pamět, pokud je bytekód nebo AST nejprve kompilován. Adaptivní optimalizace je doplňkovou technikou, ve které interpret profiluje běžící program a sestavuje své nejčastěji kompilované části do nativního kódu. Obě techniky jsou několik desítek let staré, jsou uvedeny v jazyce, jako je [[Smalltalk]] (1980). Just-in-time kompilaci získala ~~většií~~větší pozornosti mezi implementátory jazyka v posledních letech, s jazyky [[Platforma_Java\|Java]], [[Python]] a [[.NET\|.NET Framework]] nyní všechny obsahují [[JIT]]. == Historie ==

Interpret (software): Porovnání verzí