Vlákno názorů ke článku JSON pro C++11 s immutabilním DOMem. od unicode - Atomické operace nejsou rozhodně zadarmo. Navíc lokální alokátor...
-
unicode (neregistrovaný)
Atomické operace nejsou rozhodně zadarmo. Navíc lokální alokátor není pouze o rychlosti alokace, ale je hlavně o lokálnosti. Pokud vytvářím JSON dokument, a můj jediný cíl je ten dokument serializovat do stringu, tak to nejlepší co můžu udělat je vytvořit lokální alokátor, který bude vracet adresy blízko sebe. Při takovém návrhu se minimalizuje cache miss, který může stát stovky cyklů. Navíc takový dokument můžu uvolnit třeba jedním zavoláním free() (nebo žádným, pokud si vystačím se zásobníkem), a nemusím se starat o uvolňování interních struktur, které jsou všechny alokované z jednoho většího bloku. Takto to dělá např. V8 engine. V podstatě každá high-performance knihovna si řeší alokaci po svém, protože to co nabízí C/C++ jsou generické alokátory.
Jinak netvrdím, že ta knihovna je špatná, jen tvrdím, že není navržena s ohledem na výkon.
-
No s výše uvedeným pull requestem bude možné zapojit si k tomu vlastní alokátor. Jinak genericky rozumím, šlo by to napsat komplet jako šablony, které by přijímaly alokátor jako další typ, ale ta složitost a přehlednost kódu by byla trochu někde jinde.
Destrukce DOMu není jen uvolnění paměti, ale hlavně destrukce těch objektů. Protože je immutabilita ruku v ruce se sdílením, pak do hry vstupuje i nutnost při destrukci procházet objekty a odečítat reference aby se vědělo, co je třeba všechno zničit. Je to víc zaměřeno směrem, že budu data v DOMu držet spíš než abych jen načet, vyexrtahoval a zničil, případně zaalokoval sestavil a odeslal a uvolnil.
Původně jsem měl v článku v odstavci Motivace, kde jsem se zamýšlel, zda je lepší mít to jako extractor a serializátor dat, nebo jako mnohem bohatší nástroj. Protože serializaci do JSONu nepotřebuju dělat přes DOM a čtení JSONu mohu dělat pomocí události bez překladu dat z jednoho uspořádání do druhého
ČLÁNKY DO MAILU