W3C home > Mailing lists > Public > www-style@w3.org > June 2003

Re: XPath as CSS-selectors?

From: Herr Christian Wolfgang Hujer <Christian.Hujer@itcqis.com>
Date: Fri, 20 Jun 2003 22:12:02 +0200
To: Boris Zbarsky <bzbarsky@MIT.EDU>
Cc: www-style Mailing List <www-style@w3.org>
Message-Id: <200306202212.36481.Christian.Hujer@itcqis.com>

Hash: SHA1

Hi Boris,

On Friday 20 June 2003 21:41, Boris Zbarsky wrote:
> Herr Christian Wolfgang Hujer wrote:
> > I think XPath is fast enough.
> > Experience: Use of large XPath expressions (>250) making extensive use of
> > the document() function several times (>10) in each single xslt
> > transformation of websites (pages >250) using Ant, Xalan, Xerces and
> > Java.
> And the times involved were?  It's hard to work with blanket statements
> unsupported by hard data.

Okay, here's some time data, though I don't think it's useful for our problem.
My Ant script (ant clean all) takes 5 minutes 56 seconds to run.
It does: validating 64 xml files, transforming 64 xml files to xhtml, 
validating 141 xhtml files, transforming 141 xhtml files to xhtml (adding 
layout using these complex xpath expressions and lots of document()), 
validating 141 xhtml files, transforming 141 xhtml files to html, tidying 141 
html files, copying some files, rasterizing 4 svg files, compressing about 
300 files takes 5 minutes 56 seconds altogether.
Keep in mind, that Xalan and Xerces are not known for their speed, I know 
saxon already is much faster and it could be that xsltproc (from libxslt) is 
even faster.
One of these really heavy transformations takes 1-2 seconds. But the XSLT and 
XPath expressions involved there really are somewhat complex. It's >600 lines 
of XSLT code and more than 50 document() function calls, most of which are 
used to generate a meaningful <head/> and the navigation bar and some of 
which are in loops (xsl:for-each or an xsl:tempate used several times).
It's far away from a scenario that could be compared with CSS.

A real time measurement would involve a representative XHTML document and a 
set of XPath expressions selecting nodes similar to CSS Selectors invoked 
directly from a performance test library to apply a virtual stylesheet and 
generate the properties attributed formatting objects¹ tree...
So I can just tell from my *feelings* that I have from my experience with all 
(¹ in the context of CSS formatting objects, not XSL formatting objects...)

> > If the implementation of XPath in a UA would be only half as fast as that
> > of Xalan (which isn't know for speed anyway), instant response for any
> > web page <200kB is guaranteed I think.
> "Instant" means "under 5 msec" in the use cases we're talking about
> here.... because the UA is being given 10 msec to reresolve style and
> reflow/repaint/whatever as necessary.
Well, I don't think XPaths have significantly less performance than CSS 
Selectors /as long as the complexity stays the same or is just slightly more 

> Not saying it's not doable, I just have no data to work with, since my
> XPath experience is severely limited.

Thank you for objecting on the performance, anyway, because that's really an 
important point in a usual UA (since the resources of Moore's Law are always 
eaten by well-know virusses like Solitaire or Minesweeper ;-).
It really makes a difference wether it's under 5 msecs or 100 msecs, because 
100msecs makes it really inapproproate for dynamic HTML.

- --
Christian Wolfgang Hujer
Geschäftsführender Gesellschafter (Shareholding CEO)
Telefon: +49  (0)89  27 37 04 37
Telefax: +49  (0)89  27 37 04 39
E-Mail: Christian.Hujer@itcqis.com
WWW: http://www.itcqis.com/
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)

Received on Saturday, 21 June 2003 03:57:54 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:07 UTC