Re: Compiling XML, and its replacement

[Berin Loritsch <bl...@apache.org>]

Stefano Mazzocchi wrote:
> Berin Loritsch wrote:
> 
>> BTW, My Binary XML project (http://d-haven.org/bxml) has the ability
>> to compile an XML document into a Java Class (I know this is nothing
>> extraordinary as XSP has been doing it for years).  However what is
>> very different from XSP is the following:
>>
>> 1) No Java file is ever written (it uses BCEL)
>> 2) No Class file *needs* to be written (although it is an option)
>> 3) The original document name and the line numbers are part of the
>>    generated source code.
>>    * That means the Stack trace has debug information you can
>>      use.
> 
> 
> This has nothing to do with my rants about how stupid the xslt syntax 
> is, but I would be interested to see actual performances between your 
> approach to compiled xml and mine (the one that currently cocoon uses 
> for the cache).

I understand.  However, if the language generates SAX events, it works
pretty well to compile the non XML representation.

> This is in light of the compiled/interpreted question. I think it would 
> be kind of cool to have a serious benchmark between the two approaches, 
> because this would be very helpful on the recent discussion on XSP.

It would be.  However the real performance tradeoff that I am seeking
to gain is in the CallBack facility which has only been partially
defined and implemented.

> I mean, the fact that you aren't generating the source code, well, 
> that's nice from an implementation perspective (I thought about making a 
> BCEL java assembler for XSP but then stopped because it was simply too 
> complex and not really needed now that we have the superb eclipse 
> compiler) but it's nothing different from XSP.

The major difference between what I have and XSP is that we actually
have line numbers that correspond to the original XML document :)
That makes debugging 100% easier.

> So, you are, in fact, unrolling a big loop of sax events, while my xml 
> compilation approach works at serializing the sax events in a 
> easy-to-be-parsed-later binary format.

For now.  Yes.  Eventually everything gets called the same way--so it
would be interesting to see authoritatively if the HotSpot would have
any reason to perform some optimizations.

> I would expect my approach to be faster than yours on modern virtual 
> machines because hotspot can optimize the tight binary SAX reparsing 
> code, while your approach will never reveal any hotspots.

There's only one way to find out.  To keep things as similar as
possible, both sources need to be compiled and in memory.  Then we
need to read the documents.

The interesting benchmarks are server load and scalability.  Just
because something is technically faster doesn't mean it scales well.

> I'll also be interested to see how different the performance gets on 
> hotspot server/client and how much it changes with several subsequent runs

Hmm. Anyone know of a XML parser benchmark out there?

> Too bad I don't have any time for this right now... but if you want to 
> do it, it would be *extremely* useful not only for you but also for the 
> future of compiled/interpreted stuff in java on the server side.

Problem is time.  It took me a year to find time for Binary XML, and
I only got it this far.  Who knows, I will probably get to it
eventually, but if someone has a benchmark that they already know about,
they could do the benchmark too.