Vítejte na blog.vyvojar.cz Přihlásit | Registrovat | Pomoc

Vlko napísal ...

.. mostly harmless ...
OT: Reakcia na clanok "Optimalizace uložení dat v Open XML" - doplnenie

Pri dnešnom tradičnom rannom prechádzani bookmarkov mi zrak padol na článok Optimalizace uložení dat v Open XML a musím sa priznať, že ma tento článok úprimne povedané vytočil.

Je jasné, že článok má PR razenie a je napísaný štýlom, ktorý ja osobne neznášam (cielené výber dôkazov, zvýhodňujúci iba jeden produkt). Je tam prezentavaná vo vynikajúcom svetle implementácia, ktorá odporuje podstate myšlienky.

Podstata XML

Podľa môjho názoru bol formát XML zavedený aby dokázal popísať určitý formát dát tak, aby tento formát bol umožnený prečítať nielen stroju ale najmä človeku a to z jednoduchého dôvodu:

Dáta musia byť čitateľné aj keď aplikácia, ktorá ich spracuváva už neexistuje.

Polemika 

A to je podľa mňa to najdôležitejšie a tuto základnu premysu autor článku nepochopil. Čo jasne vidieť z jeho záverov. Viď bod 1a

1.       Formát optimalizovaný pro ukládání velkého množství dat.

a.       Často se opakující elementy mají jedno písmenné názvy. Čte je počítač, ne člověk.

 

Bohužiaľ práve XML formát je určený na to, aby vedel čítať aj človek. Mam na to jednoduché vysvetlenie:

Zoberme si dobu o 30 rokov. Software bude uplne niekde inde a my sa budeme potrebovat dostat k datam, ktore robil nas dedko v exceli a vyexportoval to v Open XML. Budeme vediet z jednopismenovych popiskov dostat strukturu dokumentu?

Autor ale pokračuje

c.       ODF používá stejnou strukturu tabulek pro Calc i pro Writer, i když potřeby tabulek jsou jiné v textovém editoru a tabulkovém kalkulátoru.

 Ano to je pravda, ale len pre autora. Ja osobne používam tabuľky vo word dokumentu a rád by som použival word štruktúrovane texty v excel tabuľke.

A hneď nasleduje:

2.       Jednodušší XML. Paměťová struktura, pro uložení XML souboru bude jednodušší. Cesta k hodnotě buňky:

 Opäť musím autora sklamať, ale jediná nevýhoda, ktorá z väčšej veľkosti popiskov xml nodov a atribútov vyplýva to, že daný xml súbor bude pomalšie rozparsrovaný, nič ale nehovorí, koľko v skutočnosti takto rozparsovaný xml dokument zaberie v pamäti. Táto neznalosť je jednoznačne vidieť už v predchádzajúcom texte:

Podstatně důležitější pro zpracování je dekomprimovaná velikost. To je to, co nám bude zabírat operační paměť.

 A nebude a nebude a nebude:), jedine ak si z nejakého neznámeho dôvodu budeme držať v pamäti aj pôvodnú nerozparsovanú hodnotu dokumentu.

A ďalší subjektívny názor:

3.       Texty uloženy v jiném souboru než číselná data.

a.       U velkého množství scénářů, mě texty nezajímají, stačí číselné hodnoty.

 Aj ja mám oveľa vätšie množstvo scenárov, kde ma texty zaujímajú a pri parsrovaní dokumentu pomocou xmlreadera budem musieť doťahovať tieto texty z iného súboru, čo teoretický spomaľuje výkonnosť. Ale to je len jedna implementácia.

b.      Texty jsou sdílené pro všechny listy a zbytečně se neopakují.

 Aké texty? To je tam zoznam všetkých použitých slov? A miesto textu ukladáme len zoznam identifikátorov použitých slov v texte? Silne pochybujem. K tomu pri vlastnom implementovaní formátu pravdepodobne budem musiet použiť hashovanie každého textu, tak aby sa mi tam neobjavoval viackrát.

Záver

Članok dokazuje ale opačnú vec a to pre mňa ako programátora a možného implementátora OpenXML formátu do mojej aplikácie:

Implementácia bude veeeeeľmi zložitá.

Miesto  veeeeeľmi máme na slovensku výraz začinajúci na k, ale ten z morálneho hľadiska nepoužijem.

Pridám ešte pár myšlienok pre polemiku:

  1. Ak chcem použivať XML formát vyberám si ho preto, aby som našiel čo najblišiu implementáciu blízku k binárnemu formátu, alebo taký formát, ktorý ma najvätšie predpoklady pre zachovanie obsahu dát?
  2. Mám len ja pocit, že OpenXML je 1 k 1 implementácia binárneho formátu? Spojena s balastom prenášaným od počiatkov existencie office balíka. Vid specifikácia dátumov, ktora nie je shodná so žiadnou ISO normou.
  3. Ako sa takýto článok dostal na portál, ktorý ma v názve Czech/Slovak Developer & Platform Group a je určený pre vývojarov a pravdu povediac sa nedajú opiť rožkom?
  4. Stálo mi za to reagovať?

A možete ma ukameňovať.

APPENDIX

Spravil som si taky maly testovaci programček, ktorý načíta ods, alebo xlsx subor a spočíta čas a kolko pamäti zaberie takýto dokument v pamäti.

Ako dáta som použil cenník pc komponent z webu s cca 10 k položiek, ktoré som zdvojnásobil a pridal stĺpec s dátumami, ktoré boli random nagenerované, k stiahnutiu tu.

Zdrojovy kód možete stiahnuť tu.

Príklad sa spúšťa príkazom test.bat a je k stiahnutiu tu

Nuž a tu je moja metodika:

  • rozzipovanie xml dát, najde v ňom pre odf: content.xml a pre openxml: sheet1.xml a sharedStrings.xml.
  • načítanie xml dát do XMLDocument-u
  • výpis koľko tieto dáta zaberajú v pamäti (používam jednoduche GC.GetTotalMemory(true))

A tu sú výsledky:

       
\Debug>echo ODF test
ODF test

\Debug>xmltest data.ods
Start           281˙408,00
office:document-content
00:00:03.0143344
End          74˙625˙572,00 with difference        74˙344˙192,00

\Debug>echo OpenXML test
OpenXML test

\Debug>xmltest data.xlsx
Start           281˙408,00
sst
worksheet
00:00:02.3233408
End          71˙303˙500,00 with difference        71˙022˙120,00

 Načítaný OpenDocument teda zaberá v pamäti (stav pamäte su tie hodnoty za Start a End a za with difference je napisana rozdielova hodnota pamati) o 4.6 % viac miesta, samozrejme tým, že je jeho formát ukecanejší, jeho parsrovanie trvá dlhšie.

Zajtra ešte pridám appendix 2, kde ukážem ako v každom formáte vyzerá jeden riadok tabuľky.
 

 


 

Posted: Wednesday, April 25, 2007 10:42 AM by vlko
Vedeno pod:

Komentář

dotnet napsal:

To je jako se rozcilovat na diskuzi na idnes :-) Kritizovat nekoho kdo jen kopiruje a prezentuje neci praci nema smysl ;-)

# April 25, 2007 12:30 PM

mjurek napsal:

Nechci polemizovat o clanku, ktery kritizujete - dle meho soudu dost povrchne a bez jakychkoliv dukazu. Spise by mne zajimalo, co byste rad videl jako alternativu.

Je jasne, ze OpenXML je poplatne funkcnosti Office, stejne jako ODF je naprosto poplatne OpenOffice/StarOffice. Jakykoliv format vymysleny od stolu by byl pouze omezene kompatibilni s existujicimi produkty, coz by bylo zcela neprijatelne jak pro vyrobce produktu, tak pro jejich zakazniky.

Nemyslim si, ze je typickou vyvojarskou ulohou generovat dokumenty na zelene louce. Daleko castejsi je doplnovat do nejake sablony datove udaje (jmena, castky, adresy apod.) - a to ma OpenXML vyresene velmi dobre.

# April 25, 2007 10:15 PM

vlko napsal:

to mjurek: priznavam sa dost povrchne (nabuduce si taketo kritiky odpustim), pretoze kritizujem podstatu clanku a to porovnavanie xml dokumentov na zaklade velkosti vysledneho suboru.

k druhemu odseku:

ODF nebol designovany pre potreby OO (http://en.wikipedia.org/wiki/OpenDocument), OO ho len implementuje narozdiel od OpenXML, kde bola postupnost opacna, tak ako sam pisete.

k tretiemu odseku:

Vzdy je tu ale promile populacie programatorov, ktory chcu spravit napr export filter pre zostavy.

Uz len samotny popis openXML ma 6095 stran vid http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=45515&scopelist=PROGRAMME

narozdiel od ODF, ktory ma 722 stran vid http://www.iso.ch/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=43485

# April 26, 2007 12:20 AM

bst napsal:

to vlko:

Takove povrchní srovnávání velikosti normy (popisu) formátu zrovna není moc dobrým argumentem. Zvlášť, pokud jeden (ten menší) z dokumentů je čistým popisem, zatímco ten větší obsahuje velké množství podrobných popisů i příkladů, které právě mnozí programátoři dost ocení při implementaci.

Osobně mi připadá Open XML přehlednější (a to i pro ruční editaci), každý to může vidět jinak.

# April 26, 2007 9:36 AM

vlko napsal:

to bst: hmm, tuto dilemu asi nerozsudime, zostane to na uzivatelovi, preto este ponuknem priamo odkazy na specifikacie, urcite sa to niekomu hodi

OpenDocument:

http://www.oasis-open.org/committees/download.php/19274/OpenDocument-v1.0ed2-cs1.pdf

OpenXML:

http://www.ecma-international.org/news/TC45_current_work/TC45-2006-50_final_draft.htm

Este by som rad podotkol, ze neuprednostnujem ziaden format, moja reakcie je len na hlavnu myslienku daneho clanku a to, ci je mozne hodnotit jednotlive formaty podla dlzky nazvov tagov a atributov? Pretoze to je hlavny dovod, preco ma ODF vatsiu velkost.

# April 26, 2007 10:12 AM

Gwamb napsal:

>>> ODF nebol designovany pre potreby OO (http://en.wikipedia.org/wiki/OpenDocument), OO ho len implementuje narozdiel od OpenXML, kde bola postupnost opacna, tak ako sam pisete. <<<

Open Office implementuje ODF, ale jeste k tomu pridava vlastni namespaces napr. pro formule v excelovskych bunkach. Tim se takovyto dokument stava nepouzitelny v jinych ODF-like aplikaci. Obdobnym zpusobem se chovaji jine aplikace.

ODF za "vidinou byt prvni" neobsahuje mnoho a mnoho veci, ktere se ted dodavaji jako verze 1.1 a dalsi....OpenXML se snazi tam mit vse od zacatku a pokud nahodou je pouzito neco co neodpovida nejake norme, je to tam popsane - viz. zmineny datum.  

# May 2, 2007 1:52 AM

Giraj napsal:

I believe that, as voiraus governmental units continue to adopt ODF instead of OOXML, which forces their contractors also to adopt ODF, there will be a trickle-down effect.  Looking at the quality of conversion between the two formats alone tells me that NO ONE will want to use both.  So then, when the leading technology, defense, and construction contractors are told that they can use ODF or work elsewhere, what do you think they will choose?If you are a subcontractor of one of these companies, that means that you also have to choose ODF.  If you are an employee of any of the above, or if you desire to be, you will choose ODF for your resume format, meaning that recruiting firms and their software suppliers will need to move over also.In other words, assuming that the movement in government continues the way it has around the world, by the time Office 14 rolls around, Microsoft will *have* to join the rest of the world if it wants to sell its software.For consumers, having a choice of software that is fully compatible with a standard format (I know that hasn't happened yet, but it will) is a good thing, because that means that they can choose their software based on *price* and *features*, rather than what name brand is in use in their employer/school/city.  I see this as the best possible outcome.

# March 1, 2014 1:15 PM
Vytvoření nového komentáře

(povinný) 

(povinný) 

(nepovinný)

(povinný) 

Opiš čísla, která vidíš na obrázku:

Upozornění na nové komentáře

Pokud chčeš dostávat upozornění emailem na změny u toho příspěvku,tak se zaregistruj zde.zde

Odebírat komentáře k tomuto příspěvku pomocí RSS