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 time was spent on optimizing XmlPullParser on a compiled XML resource since that is critical to things like app launch time (which involves parsing layout and other XML resources). The current performance of that is sufficient but, especially for low-end devices, a 10x slow-down would very seriously negatively impact UI performance. So: if you are parsing XML as part of UI interaction, an XmlPullParser on a compiled resource should be sufficient for relatively real-time performance (just parse directly and display). A SAX or XmlPullParser on a raw XML file is most likely going to be slow enough to warrant doing in another thread and showing the result to the user when done. The DOM parser is going to be significantly slower than that. Of course this all depends on exactly what you are doing and the work that is needed outside of the raw XML parsing. On Tue, Jul 13, 2010 at 9:31 AM, DanH <[email protected]> wrote: > 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 will be in, etc) then SAX is good. If > you need to keep referring to the data, or you need to extract data > from documents that may be a bit disordered (with elements in varying > order, extraneous elements, etc) then DOM is a lot simpler. > > But, yes, DOM does take up a fair amount of storage -- no hard numbers > but I'd guess easily 20-50 times the size of the XML file. > > On Jul 12, 6:51 pm, Indicator Veritatis <[email protected]> wrote: > > 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 would stick with SAX though, until these newer ones have been > > reviewed and proven not to have major omissions and bugs. Besides: SAX > > and DOM are already in Android. If you choose one of the others, even > > Apache's Betwixt or Xerces, you will have to include it as an extra > > Jar in your build. > > > > On Jul 12, 12:30 pm, Siva <[email protected]> wrote: > > > > > Can anyone tell me the easy and fastest XML Parser? > > > > > I need guide/sample code... > > > > > please help me... > > -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected]<android-developers%[email protected]> > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en > -- Dianne Hackborn Android framework engineer [email protected] Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- You received this message because you are subscribed to the Google Groups "Android Developers" 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/android-developers?hl=en
