On 10/10/13 15:28, Axel Hecht wrote:
On 10/10/13 2:43 PM, Jeff Walden wrote:
On 10/10/2013 02:27 PM, Axel Hecht wrote:
I agree with the sentiment, but not on the eample.
Having been a peer of the XSLT module back in the days, we started
with a rather js DOM like implementation, and moved over to a pure
nsIContent etc impl, and each step there won us an order of magnitude
in perf.
But do we actually care about the perf of sites that use XSLT now, as
long as perf isn't completely abysmal? A utility company showing
billing statements, I think we can slow down without feeling guilty.
But if, say, Google Maps or whichever used XSLT (I seem to remember
*something* Google used it, forcing Presto to implement XSLT, back in
the day -- maybe they've switched now, blink thread might say if I
checked it), we might care.
Jeff
My point is, the perf was completely abysmal, and the key is to use
nsINodeInfo for the xpath patterns instead of DOM localName and
namespaceURI string comparisons. There's also a benefit from using the
low-level atom-nsID-based content creation APIs.
Nevertheless it seems worth trying — at least in an experimental way —
in case performance improvements of js and DOM APIs in the interim have
made the difference small enough not to matter. If they haven't, that's
interesting data on its own.
It may also be sufficient to adopt a presto-like XSLT implementation
where (iirc; I haven't tested and don't remember too well) you just
construct a string and feed it back through the HTML parser rather than
trying to work on the output tree directly.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
