Re: XML was RE: [GD-General] RE: A portable preferences library

[Alen L. <ale...@cr...>]

Nope, you missed the boat. :) The idea is that XML is a generic format, 
freeing you from writing your parser. There is no much point storing plain 
blobs inside XML. Then, you can just dump it with fwrite() as well. But the 
question is: If you save your vertices in x="1" y="0"...etc format, can that 
still load as fast as if you just dump 3f8000000000000...etc? (Hex dump from 
head - might have some errors ;) ). People started to argue that the 
verboseness of the format doesn't hinder its performance. I say, ok, it 
might be possible, but show me the numbers. Didn't see any yet. :/ 

Alen 


J C Lawrence writes: 

> On Tue, 16 Dec 2003 18:54:16 -0000 
> Alen Ladavac <ale...@cr...> wrote: 
> 
>> On a side note, this comment that "it is a HUGE ammount of work", is
>> based on a wrong assumption. Their problem is that the design was
>> wrong. If they went for generic binary format from the start, the work
>> would be near zero. But I digress.
> 
> No, you missed the boat. 
> 
> XML is an encoding format.  It says nothing about the data structures or
> data representation beyond the encoding.  More simply, through use of
> URI anchors and references there is little (nothing?) that can be
> represented in a serialised binary format that can't also be represented
> in XML.   
> 
> The discussion to date has on representing things like raw vertex data
> in a highly abstracted XML form.  That has obvious and unpleasant
> post-processing expenses.  If you don't want those costs, don't incur
> them: encode your already post-processed system-optimised yada yada data
> structures into XML.  There's nothing inherent to XML or binary data to
> prevent that.  You don't need to design or write your encoding format. 
> 
> XML is JUST an encoding format.  Well, it also happens to be a
> standardised encoding format, but that's more of a toolchain and code
> support issue.  At the end of the day where disk heads don't meet
> platters the effective differentials are in the storage and parsing
> overheads, not in the data structures.  The data that is represented is
> arbitrary, and for systems which don't need random reads (XML indexes
> badly) the performance differentials are invariably trivial. 
> 
> This written by someone who doesn't /like/ XML... 
> 
> -- 
> J C Lawrence
> ---------(*)                Satan, oscillate my metallic sonatas.
> cl...@ka...               He lived as a devil, eh?
> http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live. 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557