Lazy and Eager Acquisition 1 1 1 1

Lazy (líný) vs eager (dychtivý, netrpělivý) Lazy vs Eager Lazy (líný) vs eager (dychtivý, netrpělivý) 2

Lazy Acquisition 3 3 3 3

Příklad – Elektronická zdravotní karta Doktor chce zkontrolovat elektronickou zdravotní kartu Jméno Adresa RT snímky, MR, CT... Tyto údaje mohou být čerpány z mnoha zdrojů pojišťovna, servery, databáze, souborový systém Pokud má pacient mnoho záznamů (např. často absolvoval RT), načtení všech jeho snímků může trvat dlouhou dobu Je docela možné, že by se doktor zajímal jen o poslední záběry (od zranění) a ty staré by byly zbytečně načtené – zbytečné čekání Potřebovali bychom systém, který nebude záviset na tom, jaká dlouhá je zdravotní karta pacienta 4

Příklad – Elektronická zdravotní karta (Vylepšená) Mohli bychom si data všech objednaných pacientů na dnešek načíst ráno Nebo Během současného pacienta bychom si načetli následujícího ... Načteme jen data (např. textové) o tom, že dané snímky máme a pokud se lékař bude chtít podívat detailněji, tak se načte celý snímek v plný kvalitě 5

NV Lazy Acquisition – idea Práci budeme odkládat úplně do poslední chvíle, dokud to bude možné 6

Kdy? Pokud řešíme problémy jako: Získání všech prostředků na začátku není vždy nejlepší volba počáteční inicializace může trvat dlouho Není zaručeno, že všechny inicializované prostředky (plně) využijeme Je možné, že jsme některou práci dělali zbytečně 7

NV Lazy Acquisition – použití Pokud v aplikaci potřebujeme zajistit vysokou propustnost a dostupnost při omezených prostředcích Tento návrhový vzor posouvá získání prostředku na nejpozdější možný okamžik, kdy již není možné posunout danou operaci 8

NV Lazy Acquisition – členové Resource user – získává a používá prostředky (lékař) Resource – libovolný prostředek (RT snímek, jméno, záznam) Resource proxy – zprostředkovává získání nového prostředku nebo již získané prostředky prodává uživateli, zakrývá přímé vs lazy získání prostředku (informační systém) Resource provider – postará se o získání prostředku (načtení z databáze, serveru, file systému...) 9

NV Lazy Acquisition – implementace 10

NV Lazy Acquisition – implementace 11

NV Lazy Acquisition – implementace (poznámky) Resource proxy je vytvořena na začátku při inicializaci má stejné API jako Resource 12

NV Lazy Acquisition – výhody Dostupnost - systém získává pouze ty prostředky, které je třeba (nezabývá se těmi, co netřeba) Stabilita – menší pravděpodobnost zahlcení systému Optimální start systému – nezabývá se načtením dát na začátku, takže start je rychlý Transparentnost – je transparentní z hlediska uživatele Pořízení prostředku – přímé vs lazy 13

NV Lazy Acquisition – nevýhody Paměť – Spotřebovaná paměť na proxy Čas – některé získání prostředku může trvat déle Nepředvídatelnost – pokud získání nějakého prostředku budou více členů nechávat na poslední chvíli a pak se vše najednou spustí, může nastat zahlcení 14

NV Lazy Acquisition – použití Singleton objects (lazy instantiation) Operating systems (library loading) Haskell (lazy evaluation of expressios) JIT(Just-In-Time) překlad 15

Eager Acquisition 16 16 16 16

Příklad – Operační systém V operačním systému potřebujeme v různých případech: Dynamicky alokovat paměť Navázat síťové spojení Spustit vlákno pro nějakou úlohu Získání takových prostředků může trvat netriviálně dlouho Během toho mohou vzniknout ještě různé výpadky, čekání Potřebujeme mechanismus, který bude připraven co nejdříve vyhovět danému požadavek ... 17

Příklad – Operační systém (vylepšený) Globální proměnné pro jednotlivé prostředky Nebo Alokace na zásobníku ... Prostředky si někde připravíme v časovém rozmezí od startu po prvé použití daného prostředku 18

NV Eager Acquisition – idea Práci se snažíme provést co nejdříve 19

Kdy? Pokud získání prostředků: Za runtime může způsobovat netriviální zdržení aplikace Musí být rychlé a předvídavé Musí být spravedlivé k ostatním 20

NV Eager Acquisition – použití Návrhový vzor popisuje, jak je možné získání prostředků optimalizovat předčasným získáním, před jejich prvním použitím Vytvoří se kontejner, do kterého se (v době od startu po jejich použití) připravují dané prostředky V případě požadavku je máme hned k dispozici 21

NV Eager Acquisition – členové Resource user – získává a používá prostředky (aplikace, program) Resource – libovolný prostředek (paměť, připojení, vlákno) Provider proxy – Udržuje získané prostředky v container-u, které zprostředkovává a předává uživateli. (Thread pool, Memory pool,...) Resource provider – stará se o získání prostředku, je možné vynechat přímým použitím Resource (OS - přidělení paměti, vlákna, připojení, …) 22

NV Eager Acquisition – implementace 23

NV Eager Acquisition – implementace 24

NV Eager Acquisition – implementace 25

NV Eager Acquisition – implementace (poznámky) ProviderProxy Je vytvořena na začátku při inicializaci má stejné API jako Resource Udržuje container daných prostředků, který se „nafukuje“ Při požadavku vrátí daný prostředek v O(1) „Nafukování“ bychom mohli zajistit i paralelně Čas, kdy proběhne nafukování, může být konkrétně určený 26

NV Eager Acquisition – výhody Rychlost – získání prostředku může být konstantní Předvídavost – prostředky jsou připraveny v containeru Transparentnost – je transparentní z pohledu uživatele 27

NV Eager Acquisition – nevýhody Správa získaných prostředků – uvolnění paměti, likvidace ... Statická konfigurace - počet prostředků se musí odhadnout na začátku ... Zahlcení systému Pomalejší start 28

NV Eager Acquisition – použití Pooling Servery AOT (Ahead-of-time) preklad Křeček (Škrečok, Hamster, 倉鼠)  29

Lazy and Eager Acquisition - shrnutí Oba vzory jsou extrémy ... Použitím těchto návrhových vzorů optimalizujeme v programech to, že získání prostředků proběhne v ten správný moment Návrhový vzor Lazy Acquisition je vhodné použít v případech, kdy získané prostředky nejsou používány ihned Návrhový vzor Eager Acquisition je vhodné použít v případech, kdy se klade důraz na čas – např. v real-time aplikacích; dříve získané prostředky se mohou ihned začít používat 30