W3C home > Mailing lists > Public > public-exi@w3.org > November 2007

Re: TAG input to EXI WG on Efficient XML Interchange and EXI Measurements

From: Tatu Saloranta <tsaloranta@gmail.com>
Date: Thu, 29 Nov 2007 17:12:03 -0800
Message-ID: <5f7770580711291712o6fef987bxb624b2f31a69af6@mail.gmail.com>
To: public-exi@w3.org

One quick question related to one of comments:

On Nov 29, 2007 11:34 AM, Henry S. Thompson <ht@inf.ed.ac.uk> wrote:
>
> Following on from the many useful discussions at group and individual
> level which took place during the recent TPAC week, the TAG has
> arrived at the following requests and recommendations for the
> Efficient XML Interchange Working Group:
...
> Detailed comments on the Measurement documents
>
> The 2005 TAG message called for testing to involve "best possible
> text-based XML 1.x implementations", and the XBC's call for
> implementations [2] specifically called for only XML parsers, not for
> the surrounding application or middleware stacks, JDKs or Java Virtual
> Machines.  The benchmarks have not been against the best possible
> text-based XML 1.x implementations.

Given that there are multiple contestants for "best possible
text-based XML 1.x implementations" (even if not considering more
integrated approaches), would it be easy to re-run tests using
alternatives other than JAXP (which I assume means Xerces 2.7.1)?
Especially if using the same interface (SAX2).

I don't expect working group to have to try out all permutations, it
would just be interesting for others to try out alternatives, both
benefiting EXI community and parser implementors. Chosen document set
could conveivably be used as somewhat less ad hoc collection than what
is often used when developers run performance tests.
One example of areas that would likely be affected is handling of
small files -- document notes that JAXP parser was performing
relatively poorly for small files. This is consistent with
measurements of Java SAX parsers that do indicate Xerces to have
higher per-document overhead than alternatives (i.e. Xerces
performance relatively poorly amongst it peers for small docs, and
much better for larger ones). I would be interested in seeing what
kinds of relative performance profiles would other textual xml parsers
have.

-+ Tatu +-
Received on Friday, 30 November 2007 01:12:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 1 October 2008 18:12:36 GMT