Vlákno názorů k článku
Akta X: EXI čili binární XML

Precital som si vsetky prispevky a az na dva mam dojem ze tomu nikto nerozumie. Robil niekto z vas co tu pisete XML parser (a validator voci XSD vratane namespace)? Uvedomujete si ze binarne XML sluzi hlavne na to aby sa tento XML to Memory alebo XML to internal structure nemusel robit? A az ako dalsia vlastnost je ze je to mensie. O velkost tu primarne vobec nejde.
Cez kolko vrstiev obvykle prechadza XML od povedzme klienta az po databazu? Rozumiete niektorym principom Enterprise message bus?
Potom nam sem nieco mudre napiste. Iniciativa je fajn. Treba to dotiahnut do praktickych implementacii. V kazdom pripade to velmi zrychli komunikaciu.
Trochu som sa rozohnil ale ludia co trepu do veci ktorym nerozumeju ma hrozne vytacaju a este sa tvaria ze oni su prave ti mudry. Lebo ak si niekto mysli ze ludia co pobehuju okolo W3C nevedie o Huffmanovej transformacii tak mate velmi naivne predstavy o fungovani sveta hraniciace s navstevou psychologa.

Máte pravdu, mě zase rozčilujou přechytralí fanoušci XML. Takové lidi je správné popíchnout.
Doufám že jste ten praser (u XML tomu odmítám říkat parser) nepsal v projektu nebo v grantu placeném z mých daní. A když už jsme u těch parserů pro stromové datové struktury, znáte Lisp?

Parser sme pisali v kamennej dobe XML. Potom ked sme ho chceli rozsirit tak sme presli radsej na standard (Xerces), aj ked bol pomalsi. Debatu XML vs. Lisp radsej znovu neotvarajme. Po zamene ( na < a ) na > je to skoro to iste, ale to berte len ako zartovnu poznamku ;-).

Já jsem z daní poplaníků České Republiky prodrbal 100 000 (za dvě konference). Absurdní na tom je, že kdybych ty peníze neprodrbal, tak by mě z university vyhodili za neaktivitu.

Blekovi to odpouštím, je pro mě kultovní linuxový progiš a nerd par excellence. Ale kravatózní šepleď bych věšel na šibenici za ty jejich barevně sladěné kravaty.

Mozna jsem vas uplne nepochopil, ale proc do toho zatahujete Enterprise service bus? Staci treba podmnozina - webove sluzby, ne?

Pretoze raz naparsovat to musite vzdy takze je jedno kedy. Nepredpokladam ze klient bude nieco na WS posielat v binary XML. Ale prave ked to XML prevliekate po buse hore dolu a ciastocne parsujete a ohmatavate na roznych miestach tak vtedy sa ta vyhoda prejavi.

PALO! JA TI DRZIM PALCE! MYSLIM ZE BY SIS DNESKA MEL UDELAT RADOST A JIT SI KOUPIT NOVOU KRAVATU!

Dik za radu, bol som si dat vycistit obleky.

Zrychlení zpracování XML zní rozumně, ale otázka je, proč se tam teda píše o bitových polích a opakujících-se řetězcích? To mi přijde, že ani samotní navrhovatelé neměli jasno, proč to dělají.

Clanek se mi nelibi, je znacne zkresleny a vzdy rikam, ze neni nad original.

Binary XML je skvele, uz se nemohu dockat az bude vsude podporovano. Samozrejme dojde opet ke snizeni vykonu, ale procesory jsou levnejsi, nez rychlejsi pripojeni k internetu a bude velmi pekne, az napriklad takovy xmlHttpRequest() probehne o 50% rychleji diky prenosu zkomprimovanych dat.

Nadruhou stranu muze byt problem, az zacnou firmy pozmenovat ona binarni data tak, aby je vetsina lidi nemohla pouzit - na obsfukaci jsou takovi ti praseci programatori primo spicky. Obcas se nevyznaji ani ve svem vlastnim kodu, natoz my po nich. Ukazkovy priklad mohou byt jmena a hodnoty formularovych prvku na strankach T-mobile.

Mě osobně se třeba líbí EBML z Matrosky (které je velmi rychlé a přitom úsporné - proč se vlastně nedostalo do Use Cases?), tak pokud se W3C podaří během parsování zachovat výkon, ale přidat možnost neznat DTD, tak tomu budu tleskat. Jinak bych zůstal u EBML.

Hmm, teda nevim jak vy, ale ja mam prohlizec podporujici gzip a pokud to je povoleno na serveru, tak se veskere prenosy komprimuji.

Doporučil bych obyčejné 32-bitové číslo, zarovnané na hranici 4 bytů. (předpokládám, že XML komise ještě nedosahují takové výkonnosti, aby standartizovali DTD s víc jak 2^32 elementů :-)

Huffmanův kód není špatná věc, jen by člověk u každého algoritmu měl zvážit, zda v daném případě jsou výhody přinesené algoritmem větší než nevýhody. Vy si taky do poznámkového bloku nepíšete poznámky Huffmanovým kódem --- sice byste ušetřil nějaký papír a tuhu, ale ztratíte spoustu času, když to budete kódovat a pak po sobě luštit :)

Ale preco? Huffmanov algoritmus je efektivnejsi a nema 2^32 obmedzenie. Nakolko sa jedna o strojove spracovanie ziadne nevyhody to nema. Podla coho ineho by si chcel hodnotit algoritmus?

Huffmanův kód je efektivnější na zmenšení množeství dat, ale množství dat zde není úzké hrdlo --- úzké hrdlo je zátěž CPU. (gigabitový ethernet zaplácaný XML, které se rovnou stíhá parsovat? diskové pole čtoucí XML rovnou do parseru rychlostí 300 megabytů za sekundu? --- to si lze asi těžko představit)

Psal jsem HTML parser (nikoli XML) a funkce, co spotřebovala nejvíc času --- asi 30% --- dělala hledání atributů u tagů. Takže, kdybych chtěl navrhnout binární rychle-parsovatelné HTML, tak bych udělal:

- ukazatel na další atribut
- hash jména atributu (pokud to není atribut, co chceme, tak rovnou skočíme na další bez porovnávání jména)
- délka jména (memcmp je rychlejší než strcmp)
- jméno
- hodnota atributu, ukončená nulou (aby se pointer na ni dal rovnou předávat funkcím v C)

(v rozpoznávání tagů mi profiler kupodivu ani nezobrazoval moc stráveného času, důležité byly atributy)

Jak by tomu měl pomoct Huffmanův kód, si nedokážu představit.

Aka zataz CPU ked uz to bude rovno v memory like forme? Ale RAM to ustiha vzdy. Najpomalsia cast vypoctoveho systemu je stale disk. Siet a pamat je OK. Vacsina XML sa uklada az niekde na konci spracovania.
To ze ty si to nevies predstavit este neznamena ze je to zle. Podla testov ktore su spomenute v clanku prave tato metoda bola najrychlejsia. Nerozumies faktom?

A to chtějí používat tu kompresi po bitech už v paměťové formě?

Pomalost disku? Hardwarové pole zvládne 300 megabytů, ale nedokážu si představit program, který data touhle rychlostí bude nějak zpracovávat (kromě triviálních utilit typu "cp" --- ale i ty už jsou při těchhle rychlostech na hranici svých možností a konzmují skoro všechen procesorový čas).

Pomalost disku tkví hlavně v dlouhé době seeku, ta nejvíc zpomaluje aplikace. Pokud máme např. obyčejný disk do PC, tak má přenosovou rychlost 50MB/s a dobu seeku 8ms. Ale vmstat nám ukazuje pod zátěží přenosovou rychlost třeba pouze 10MB/s. To znamená, že ten disk 80% času seekuje a pouze 20% času čte. Pokud nějakou kompresí zmenšíme množství přenesených dat dvakrát, tak bude doba seeku pořád stejná, takže jsme si ve výsledku pomohli jen o 10% (a procesor jsme tou kompresí zatížili o několik stovek procent víc).

Ad ty benchmarky --- ty spíš ukazují programátorské schopnosti jednotlivých týmů, než kvalitu formátu a algoritmů. Kdyby někdo dal specifikace formátů nezávislým týmům a nechal je to reimplementovat, tak dostane benchmarky úplně jiné.

Dakujem za zahlbenie sa do problematiky diskov, ale tusite vobec na co sa ten format ma pouzivat? Databazu v tom nikto robit nebude.
Co sa tyka schopnosti, nech sa paci, mozete sa prejavit, napiste lepsi.

Tuším, že se používá na komunikaci mezi klientem a aplikačním servrem (ale ne, že bych to někdy psal). Právě proto se divím, proč se do něj snaží dostat kompresi.

A citali ste clanok? Ide o binarne XML aby sa nemuselo vzdy parsovat. Najrychlejsia implementacia pouziva mimo ine aj Huffmanovo kodovanie.

Schvalne si to zkuste. BLEK ma podle me naprostou pravdu.

Na rychlosti nacitani do pameti se o 50% kratsi delka (ktere se tak nejvys dosahne pres Huffmanovu kodovani) tolik neprojevi. Ale uspora pri parsovani by mohla dosahnout i stovek procent, pokud by bylo mozne okamzite (porovnanim) poznat tag/atribut a skocit na dalsi.

Dalsi faktor je kodovani. Aby si mohly aplikace predavat data, museji je zakodovat do XML. Pokud budou pouzivat vicemene primo in-memory format (ktery jen poskladaji do nejakeho bufferu), tento krok odpadne.

Ted nad tim tak premyslim, a kdyby nejaka aplikace chtela ve velkem binarnim XML jen neco zmenit, a pak ho zase ulozit, tak by Huffmanovo kodovani bylo velmi nevyhodne. Zbytek od te zmeny by se totiz musel bitove posunout (prinejmensim). V BLEKove formatu by se to delat nemuselo.

O com to tu pisete? Ved predsa nikto netvrdi ze v pamati to bude tiez v Huffmanovom kodovanim. To je serialova forma na prenos medzi systemami. A prave ta Huffmanova forma bola v testoch najrychlejsia.
Ja tu nemiemim polemizovat o Blackovom formate. Ten ma vobec nezaujima. Ak si myslite ze to zvladnete lepsie, W3C Vas iste rada vypocuje.
Ten format musi byt iba memory like aby bol multiplatformovy, multijazycny. Citali ste clanok, pripadne thread?

Jinými slovy tu akorát dokazujete, že je to naprosto zbytečná kravina.