> I am creating a sqlite storage support for leo. Motivation for this is > that I'm going to do a mobile client that needs to be able to handle > large leo documents in restricted amount of memory; xml file + reading > all nodes to memory at one time doesn't scale for that.
My first thought on reading this was "hey, what about binary xml?". I've never understood why a defacto standard hasn't emerged, though in my I suppose geographic-based world KMZ is a proxy. Then I read this, "The performance woe of XML"[1], which explains that the real performance & memory bottleneck is not in the storage mechanism (plan text vs binary) but in the parsing. The same article goes on to recommend the approach taken by the VTD-XML project[2], purporting to be "world's most memory-efficient ... *random-access* XML parser." (emphasis added), and fastest parser and incremental updater and many other glorious wonderful things. Anyway, maybe it will interest you and perhaps be of aid in this project. [1] http://soa.sys-con.com/node/250512 [2] http://vtd-xml.sourceforge.net/ -matt -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
