What is the best performance solution for XML generation.
My goal is to build a few simple XMLs from code. I am going to implement simple custom StringBuffer based implementation of XML Builder. From other side there are several libraries like http://code.google.com/p/java-xmlbuilder/ and http://code.google.com/p/xmltool/ which has nice DSL but I guess lack on performance.
Since my goal is build simple enough XMLBuilder with great performance I think I will build custom solution. It will featuring:
Please suggest if I am wrong on performance expectations and its probably better to use ready-made libraries.
UPDATE. Why I think the performance of standard xml builders is not very good.
Standard XML builders uses Document Builder Factory and works with classes behind the scenes. Also these classes optimized to fit all users. For example I don't need namespace support etc.
<?xml version="1.0" encoding="utf-8">
<root>
<testdata>value</testdata>
</root>
</xml>
Consider very simple XML code above. If you build with standard tools it will involve so many work just to make this simple XML. I consider that it's better to just generate it by myself using String.
UPDATE 2. Performance requirement is that code should do as many things as required to generate simple XML and not more.
UPDATE 3. Thanks everyone for great comments! Now I understand better what I need and that my initial goal was not set very correctly with word "performance". My true goal is to use simple enough solution with convenient DSL to describe the XML structure and generate the XML output.
I will use plain Java objects as DSL for XML and generate XML using XStream library which is pretty straightforward solution.
UPDATE 4. JAXB. I discussed XStream vs JAXB and found that JAXB is faster than XStream. Plus I already use JAXB in my project and I like its standard annotations. I change my mind and will go with JAXB for now because XStream was originally heavily developed at the time when JAXB was not so good as today.
I will suggest something very controversial but still ...
Make profiling and performance tests with both libraries.
If you don't have time for that, assuming something is slow would be the wrong choice in my opinion. Because if it turns out that it actually is not slow, it would save you a lot of time to use an already built and supported library/framework.
Another thought. You will need to test your completed high performance solution against the solutions already available anyway, to check if it is really high performance. So I would strongly suggest measuring the performance of the libraries available before starting your own.