[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [egov] Re: Need advice regarding XML performance issues
Good Morning, Everyone seems fixated on parsing and processing when bandwidth and transport was always the biggest performance issue with me. This could be because ships have less than optimum internet availability. The Navy's tack has always been to use XML when it makes sense. If firewalls are a huge issue, XML provides the end run to accomplish the task. Interoperability and Dynamic Discovery is, of course, XML's forte as well. I could go on with the trade-offs, but I suspect I would be preaching to the choir. Very Respectfully, John R. Weiland Information Technology Specialist GS 2210 (APPSW) Code 38 Naval Medicine OnLine Naval Medical Information Mngmt Cntr Bldg 27 8901 Wisconsin Ave Bethesda, Md. 20889-5605 301-319-1159 JRWeiland@us.med.navy.mil "GIVE ME A PLACE TO STAND AND I WILL MOVE THE EARTH" A remark of Archimedes quoted by Pappus of Alexandria -----Original Message----- From: Jouko Salonen [mailto:jouko.salonen@republica.fi] Sent: Thursday, January 08, 2004 6:35 AM To: Chiusano Joseph Cc: Duane Nickull; egov@lists.oasis-open.org; mwhughes@sandproof.org Subject: RE: [egov] Re: Need advice regarding XML performance issues Joe The test itself has been designed by IBM in 2001. The reported performance test has been run a year ago. Since that XML pull parser (XPP) has been updated and is (as far as we know) currently better. The test environment can be downloaded from: http://www-106.ibm.com/developerworks/java/library/x-injava/ We can provide the X-Fetch Performer plugin for above benchmarking framework. --Jouko -----Original Message----- From: Chiusano Joseph [mailto:chiusano_joseph@bah.com] Sent: 7. tammikuuta 2004 16:06 To: Jouko Salonen Cc: Duane Nickull; egov@lists.oasis-open.org; mwhughes@sandproof.org Subject: Re: [egov] Re: Need advice regarding XML performance issues <Quote> This document displays a performance comparison between the most common XML processing techniques according to the benchmark package published in IBM Developerworks in September 2001. </Quote> Hmmm...over 2 years old... Jouko would you have an updated version available that reflects today's current environments? Or are you confident that the results still stand today? Joe Jouko Salonen wrote: > > Dear Mr. Hughes, Duane > > As Duane says there are different aspects of "performance" in XML parsing and processing. > You might want to look at the attached XML Performance Test report and the stress curve picture. > > The report and further information can be found at: > > http://www.x-fetch.com/Component_WhitePapers_PDF/X-Fetch_Performer22_Benchma rk.pdf > > Best regards > Jouko Salonen > www.reublica.fi > > -----Original Message----- > From: Duane Nickull [mailto:dnickull@adobe.com] > Sent: 5. tammikuuta 2004 21:00 > To: John.Borras@e-Envoy.gsi.gov.uk > Cc: egov@lists.oasis-open.org; mwhughes@sandproof.org > Subject: Re: [egov] Re: Need advice regarding XML performance issues > > Michael: > > Performance is a very loaded term. We have had huge debates on this > going back to 1996 on the XML-dev list. I will try to recall some of > the points we agreed on. > > 1. Performance is affected largely by platform, programming language and > physical memory (*both heap and stack) > 2. Sax is an Event based model. I have a PPT slide that explains the > concept of SAX very clearly at > http://www.nickull.net/presentations.html. (download the one entitled > Washington - Day Three). Sax works by reading in an XML document as a > one dimensional stream of bytes. When an enough bytes are read that an > "event" is recognized, an event notice is dispatched up the stack. The > event notices are simple text messages that look something like this > > StartElement=["foo"]; > > The above event is the parsers way of telling the parent that > instantiated it that is has encountered a start element named "foo". > Once the event has been dispatched. No residual memory of the event is > kept. This makes SAX a preferable methodology for parsing when there > are strict memory requirement. > > Since XML does not contain any semantics, a parser is simply a reader. > Nothing is done with the XML except reading it, checking it for errors > and resolving entities (three mandatory items) and a fourth optional > item of validating it against a DTD or XMl Schema. The latter also > slows down parsing. > > The Java SAX implementation (Xerces), accordingly has four main handlers > (entity resolver, error handler, Validation handler and event handler. > It is up to the programmer to capture all the events that get passed up > and do something meaningful with them. *** This is the place where a lot > of performance can be gained or lost!!! Since just about all programs > that consume XML documents will eventually do something with them, the > skill of the programmer writing the handler code greatly affects things > like memory, speed etc. If you use a language like Java with automatic > garbage collection, your memory options are managed for you however you > can still tune it further. If you work in a language like C or C++ > (ANSI), the skill of the programmer is going to affect your systems > performance. > > 3. If one requires to keep a model of the XML document and run a series > of programmatic tests against it, you will likely use the DOM. DOM > (Document Object Model) works by accepting the events from the SAX > handler (* although use of sax is not mandatory) and building an in > memory representation of the original XML document. Tests and queries > can then be run against the DOM tree to test for certain conditions, > etc. Performance is greatly affected here by what kinds of tests you > will run against your XML tree. This is a point of contention for those > who advocate XML automatically written out from a model since not all > object models will result in XML that is efficient to query. IMHO - a > balance has to be struck between the modellers requirements and the > programmers/system administrators. Anyways, XML like this: > > <root> > <tag one/> > <tag two/> > <tag three/> > </root> > > will be easier on processor speed that this: > > <root> > <tag one> > <tag two> > <tag three/> > </tag two> > <tag two> > <tag three/> > ... > > if you are iterating through a deep tree looking for matches. > > Summary: > > I have studied the performance issues for a lot of years and will attest > that it is an extremely complex issue and the truths about it change > almost monthly as parsers are upgraded, new chipsets come out, new API's > to the O/S are used, newer versions of garbage collection (Java, C#) are > invented etc. To be up to date is almost impossible however there are a > simple set of rules that can probably get you 85% of the way there. > > If you are eager to delve into this subject more thoroughly, please > contact me offline and I can provide you with some links etc. > > Cheers > > Duane Nickull > > John.Borras@e-Envoy.gsi.gov.uk wrote: > > > > > TC Members > > > > Can anyone provide any pointers or advice to Michael please? > > > > If there are any commercial sensitivities about your advice then I'll > > leave you to negotiate directly with him for providing that advice. > > > > John > > > > > > "Mike Hughes" <mwhughes@sandproof.org> > > > > 31/12/2003 21:12 > > > > To > > <john.borras@e-envoy.gsi.gov.uk> > > cc > > > > Subject > > Need advice regarding XML performance issues > > > > > > > > > > > > > > > > > > Dear Mr. Borras, > > > > I am researching performance issues related to XML and need to speak > > with an expert. I understand that you Chairman of the OASIS > > e-Government Technical Committee.. > > > > I would appreciate it if you could reply to this email with the names > > of people who could provide related input, particular with regard to > > specific standards and conditions that affect performance very > > adversely. Also, I need to understand what measures, commercial or > > standards-related, are being taken to resolve such performance problems. > > > > Thank you for any assistance you can provide. > > > > Sincerely, > > > > Michael W. Hughes > > Amplicast > > Erie, CO > > USA > > > > > > PLEASE NOTE: THE ABOVE MESSAGE WAS RECEIVED FROM THE INTERNET. > > > > On entering the GSI, this email was scanned for viruses by the > > Government Secure Intranet (GSI) virus scanning service supplied > > exclusively by Cable & Wireless in partnership with MessageLabs. > > > > GSI users see > > http://www.gsi.gov.uk/main/notices/information/gsi-003-2002.pdf for > > further details. In case of problems, please call your organisational > > IT helpdesk. > > > > -- > Senior Standards Strategist > Adobe Systems, Inc. > http://www.adobe.com > > To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/egov/members/leave_workgroup.ph p. > > ------------------------------------------------------------------------ > Name: XML_PERFORMANCE_BENCHMARK.pdf > XML_PERFORMANCE_BENCHMARK.pdf Type: Acrobat (application/pdf) > Encoding: base64 > Description: XML_PERFORMANCE_BENCHMARK.pdf > > Name: stresstest.jpg > stresstest.jpg Type: JPEG Image (image/jpeg) > Encoding: base64 > Description: stresstest.jpg > > ------------------------------------------------------------------------ > To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/egov/members/leave_workgroup.ph p. To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/egov/members/leave_workgroup.ph p.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]