On Tue, Jul 13, 2010 at 12:57 PM, Mark Murphy mmur...@commonsware.comwrote:
Part of the build process converts ordinary XML into a binary XML
format that is smaller and quicker to parse at runtime.
Yeah, it's basically a pre-processed DOM (well enough of a DOM to directly
do an XmlPullParser
It should be noted that XML is really a pretty lousy language all
around -- hard to code, slow/difficult to parse, bulky. For many
purposes, if you have a choice, JSON is a better option if you need a
human-readable notation, and there are any number of internal forms
that would be better than
On Wed, Jul 14, 2010 at 1:45 PM, DanH danhi...@ieee.org wrote:
It should be noted that XML is really a pretty lousy language all
around -- hard to code, slow/difficult to parse, bulky. For many
purposes, if you have a choice, JSON is a better option if you need a
human-readable notation, and
On Wed, Jul 14, 2010 at 1:45 PM, DanH danhi...@ieee.org wrote:
I've not (yet) tried to comprehend Android's compiled XML -- is there
any sort of reference for it somewhere?
Only the source:
DOM consumes memory and creates load of object (for big XML files),
but DOM is easy to work with. SAX is event driven, but programming
modell is awkward.
There is pull XML parser in android though - like SAX but you are in
control.
But usually you like to have you objects out of XML - so you
I've had the best luck with SAX. It's the fastest I found and I use it
in my application that handles very large XML files and it does the
job very quickly.
I think I saw a tutorial on anddev.org about how to implement SAX in
your application, but any tutorial on the net (desktop or mobile -
The choice between SAX and DOM is partly one of simplicity vs speed/
compactness, and partly a matter of what sort of consumption model
you have. If you're only going to scan through the XML once, and you
know what data you want, and it's pretty well formed (you know
precisely what order elements
As a very rough sketch, the performance you can expect is:
SAX is 10-100x slower than XmlPullParser on a compiled XML resource.
DOM is 10-100x slower than SAX.
(XmlPullParser on a raw XML file is slower than SAX, but not an order of
magnitude.)
For some context on that, a significant amount of
I did some research on the difference between SAX push/pull parsers.
The consensus was that generally they are within an order of
magnitude, the speed varies somewhat depending on the data, and that
there is a factor of the preference for programming push vs pull.
You noted that there is a marked
On Tue, Jul 13, 2010 at 3:27 PM, Frank Weiss fewe...@gmail.com wrote:
You noted that there is a marked difference, in favor of pull, for
compiled XML resource. What does that mean and why would it make
such a differnce?
A compiled XML resource is an Android resource that is in XML. Like,
say,
Not super-fast, but javax.xml.parsers.DocumentBuilder.parse is simple
to use.
But of course one needs to know what to do with the parsed file
afterwards. DocumentBuilder produces a org.w3c.dom.Document object
which you then must navigate by working your way through the nodes or
by using xpath
SAX is faster than DOM. Easier too, if you don't mind viewing
everything as event driven. Rumor has it there is something faster,
but I am not convinced it is anything more than rumor. But do a Google
search xml parser sax dom faster and see if you think Piccolo or
NanoXML are worth checking out.
I myself use the android.sax.* classes and the
org.xmlpull.v1.XmlPullParserFactory that's configured to use the
org.xmlpull.v1.sax2.Driver class for the actual hard work.
(I wrapped some extra classes of my own around these (android.sax.*)
to better track the the current context (i.e. which
13 matches
Mail list logo
