[xquery-talk] [ANN] XQuery in the Browser, JavaScript Edition

[Peter Fischer]

On 01/03/2011 09:02 PM, Michael Kay wrote:

Dear Michael, all,

> Congratulations.
> 
> As far as I can see, the architecture is the same as I'm using to get
> XSLT 2.0 on the browser
> 
> http://saxonica.blogharbor.com/blog/_archives/2010/11/16/4681337.html

yes, this was also my impression when I read your description.

We took the MXQuery codebase, ripped out (and rewrote) the parts that
would not compile to get a first working version. After that we
gradually re-introduced features by relying on Apache Harmony code
(since it uses the Apache 2 License), GWT helper classes (for time and
regular expressions) as well as hardcoding some of the dynamic parts
(e.g. the function library management). The only major part currently
missing is support for normalize-unicode().

Since MXQuery was designed to run on mobile and embedded Java platforms,
we already had an abstraction layer in place and were also quite
conservative on what APIs and language features to use. It turned out
that GWT uses a different subset of J2SE than J2ME does, so the
abstraction layer did not completely cover our needs and we had to
change existing core code.

> You seem to have the size of the Javascript down to about 189Kb, which
> is impressive - for XSLT 2.0 I'm having difficulty getting it much below
> 900Kb. Any feedback would be welcome on (a) how to reduce the size, and
> (b) how important you think the size is. (Do you, for example, partition
> the executable so that the code for "big" functions like
> normalize-unicode() is downloaded on demand?)

As usual, there are several numbers to measure :)

It seems that you measured in a browser using something like Firebug.

We observed that even the obfuscated code could still be compressed by a
significant amount (around 75 %). As a result, we have enabled gzip
compression on the web server using mod_deflate - which was an easy win.

The "true", uncompressed size is around 700 KB, as seen when you unpack
the Zip file.

For the remaining size difference, I could see several reasons:
- normalize-unicode() is not included yet
- MXQuery seems to have a somewhat smaller code size than Saxon, maybe
due to missing features (e.g. much more restricted optimization)

We do not yet use load-on demand, but it is clearly an option for the
future.

In terms of the importance of size reductions: We think that it matters
for three particular cases: 1) initial download times 2) JS compilation
times 3) limited caching on mobile devices.

> Michael Kay
> Saxonica

Regards,
Peter Fischer