Today I got a nice comment about “Fast XML DOM” script consumption being more of Ron Hess’s “XmlDom.cls”. That surprised me and I thought why don’t give a try and publish the results.
Benchmarking – Fixture
The most important thing to get benchmarking transparent and easy for everybody to reproduce was to search a decently big XML document to perform operations on. For this I decided to pick any public XML Atom feed, and decided to use it from a google code project feed. Here is the link to this xml.
Apart from that, for first round of bench marking, I picked two other criteria’s for benchmarking both the APIs. These are
Benchmark#1 – DOM Creation: This operation is pretty heavy as it involves creating DOM structure from a XML string.
“Benchmark#2 – getElementsByTagName() API Call”: This is pretty popular and nice API to test how well a XML API performs on parsing XML structure to give matching nodes for a name.
“Benchmark#3 – getElementByTagName() API Call”: This API call is pretty similar to that to the above one. But its performance depends on the way its implemented.
To keep this benchmarking simple and extensive for future a new class “TG_XMLDOM_BenchMarks” has been added to the API. You can check it to see how I am benchmarking.
Benchmark#1 – DOM Creation
Results:
INFO|XmlDom.constructor() -> Scripts Used : 4804 ,time consumed : 264
INFO|TG_XmlDom.constructor() -> Scripts Used : 26 ,time consumed : 18Benchmark#2 – getElementsByTagName API call
Results:
INFO|XmlDom.getElementsByTagName() -> Scripts Used : 795 ,time consumed : 28
INFO|TG_XmlDom.getElementsByTagName() -> Scripts Used : 560 ,time consumed : 55Benchmark#3 – getElementByTagName API call
Results:
INFO|XmlDom.getElementByTagName() -> Scripts Used : 798 ,time consumed : 27
INFO|TG_XmlDom.getElementByTagName() -> Scripts Used : 38 ,time consumed : 2I am glad benchmarking started and resulted well. I will doing more bench marking in coming days. This will give Fast XML DOM users/developers more confidence on the API and will help us figure out more areas for polishing and optimizations.
Launched in 2015, used by 9000+ worldwide users. It's a suite of tools for Salesforce consultants, architects, admins & developers.
Comments (9)
Anonymoussays:
April 12, 2010 at 12:49 amThe saving on the DOM initialization is good.What about getElementByTagName (note singular). Most programs (like mine) would make extensive use of this function and call it many times.I think to make it a good comparison you should consider extracting every field of the feed such as name, title, content, etc.
Anonymoussays:
April 12, 2010 at 5:26 amI worked on optimizing getElementsByTagName() because thats used internally by getElementByTagName() too. I have to add more to the benchmarks and will do more optimizations. I am doing this project part time. So if you can spare sometime to do the same that would be great. So that will be nice help and will carry on the Open Source spirit. TG_XMLDOM_BenchMarks.cls is the class having benchmarks. Other details are here : http://www.tgerm.com/2010/04/fast-xml-dom-getelementsbytagname.htmlI would say apart from saving script statements to an extent this API is also an easy to use wrapper over Spring 10 XML DOM classes. So I would say after Spring 10, rather using Spring 10 XML classes, it would be much easier to use Fast XML DOM. But yes, any saving to script statement is worth, and will help making api more stable and robust.
Anonymoussays:
April 12, 2010 at 10:46 am@VB I updated this blog post with benchmarks done after my latest optimizations. I also added getElementByTagName (Singular) as you suggested. I would be covering rest of the APIs too in the benchmarks.Hope this will give you more confidence on the API. I would like to thank you again for using the Fast XML DOM API and providing useful feedback. It really motivated me to take optimizations to next level.
Anonymoussays:
April 13, 2010 at 4:24 amHi Abhinav, I've tried your updated XMLNode class and in my code it makes an incredible amount of difference! My initial tests show a rough 90% (or 10x!) reduction in script statements.I really appreciate your efforts and your contribution to the community. Thanks for this great library!
Anonymoussays:
March 16, 2011 at 12:59 pmThanks for appreciating @Tim, thats true unfortunately CDATA is not supported by Apex DOM API http://www.salesforce.com/us/developer/docs/apexcode/Content/apex_classes_xml_dom_xmlnode.htm#node_types_title
Anonymoussays:
April 2, 2012 at 9:24 pmHi Abhinav, Any Idea why is the 2nd benchmark has a huge difference when compared to the other two??
Anonymoussays:
April 2, 2012 at 9:24 pmHi Abhinav, Any Idea why is the 2nd benchmark has a huge difference when compared to the other two??
Anonymoussays:
April 2, 2012 at 9:24 pmHi Abhinav, Any Idea why is the 2nd benchmark has a huge difference when compared to the other two??
Anonymoussays:
April 3, 2012 at 4:52 amSathya,BenchMark 2 is not a big diff, the other ones are i.e. 1 and 3. The reason being the XMLDOM.cls parses the whole XML using XmlStreamReader and creates a DOM structure. This takes a decent byte of script lines, the same is not the case with new Apex Dom.Document library as its system class.