Registry mají dvě poměrně zásadní nevýhody: je velmi obtížné je nějak jednoduše verzovat včetně možnosti mergování změn a nelze je editovat bez speciální aplikace; na textové konfiguráky stačí libovolný editor včetně Poznámek z Windows Mobile.
Co je pro uživatele Linux novinkou je fakt, že k optimalizaci není třeba rekompilace aplikace
To není novinka. LLVM tohle dělá dokonce ještě lépe, bez větvení aplikace; jednoduše při startu upraví kód aplikace, aby používala tu možnost, kterou je nejlepší použít. Ale proč to řešit při běhu nebo startu aplikace, když to lze vyřešit už při nasazení?
http://www.root.cz/zpravicky/podil-windows-klesl-pod-90/240979/
V tom příspěvku jste tvrdil: Uvedomte si ze unixovy konfigurak je porad obycejny textovy soubor (everything is file) a podle toho s nim muzete manipulovat, optimalizovat ho (jsou velmi ucinne metody optimalizace vykonu), menit a zalohovat.
No a mě by zajímalo, jak optimalizujete konfiguráky tak, aby se z nich rychleji četlo, či se do nich rychleji zapisovalo. Předpokládal jsem, že alespoň víte, co jste psal.
Deamon není file, zvuková karta není file, okno není file
Technika everything is file neříká nic o oknech, démonech ani zvukových kartách, ale o jejich komunikaci mezi sebou a se systémem. Vůbec ji nezajímá, kdo si povídá a s kým (samozřejmě pokud má příslušná oprávnění). Zrovna u té zkukové karty je zvukový výstup většinou datový proud, tedy soubor.
Například pokud máte větší cache, můžete prodloužit velikost jednotlivého zpracovávaného bloku dat, což za vás LLVM, .NET ani Java neudělají.
LLVM zvládne i to. Resp. kde by to zvládl kompilátor při překladu zdrojáku, tam to zvládne i LLVM (třeba přes nějakou konstantu načtenou z runtime). Na druhou stranu větvení kódu tohle nezvládne, přinejmenším ne dynamicky.
Dalším hřebíčkem do rakve je fakt, že optimalizace je třeba primárně u malých částí kódu, které se ale často optimalizují v ASM (například explicitní použití MMX/SSE/SSE2 instrukcí).
Tak se vyrobí tři větve optimalizované v assembleru (to LLVM taky umí) a před spuštěním se napevno vezme ta, která je podporovaná. Vůbec nevidím, kde má větvení kódu navrch.
Aha, LLVM zvládne prodloužit velikost jednotlivého zpracovávaného bloku dat, když si to tak napíšete. Naproti tomu bez LLVM si to tak musíte napsat. Kde je tedy ta výhoda LLVM?
Ta hlavní výhoda je, že se to optimalizuje až na cílovém stroji tamnímu hardwaru na míru, ne při překladu u vydavatele na pár základních konfigurací.
Opět pokud už máte tři optimalizované větve v ASM, tak není třeba LLVM. Samozřejmě to, že se vybere jedna z nich již při inicializaci aplikace, je běžné, a nepřináší to overhead.
To sice ano, ale přináší to overhead při vývoji, protože musíte to samé napsat třikrát v assembleru, v LLVM to stačí napsat jednou a v C nebo C++ (což samozřejmě snižuje cenu za vývoj a zvyšuje spravovatelnost kódu a taky zjednodušuje portování) a LLVM to optimalizuje automaticky podle aktuální konfigurace stroje (stejně jako by to udělal kompilátor), na kterém se to spustí. Navíc LLVM umí provést ten překlad jen při prvním spuštění, pak už je aplikace rovnou spouštěna optimalizovaná.
Merge změn dvojklikem na .reg soubor je obtížný?
To není merge, ale přepis. Vůbec to neřeší konflikty ani to neumí spojovat více možných větví vývoje konfigurace.
. Je to rychlejší vyhledání hodnoty (binární strom vs slow seek konfiguráku)
Většinou není. Naprostá většina aplikací ten konfigurák projde při spuštění nebo změně, jinak jej drží zpracovaný v paměti. A to je mnohem rychlejší, než se neustále dotazovat do nějakého binárního stromu na disku.
o hodně rychlejší zápis (konfigurák je nutné kompletně přepsat)
Zapisuje se typicky při změně nastavení aplikace a při jejím ukončení a to se tak často neděje, takže tohle není problém.