Such a construct would only really be useful if you could
rely on the
processor evaluating all the items in a for-each in order,
but that
is explictly not the case. One of the benefits of a side
effect free
language is that it is naturally parallelisable. ....
I'm just wondering now why this explanation is not given with
the W3C norm.
It's not the job of a standard or specification to educate its readers or
justify its approach. That needs to be done, but doesn't belong in the
specification.
I have another limitation: on my laptop with Pentium M 2GHz,
Saxon (Java) takes 100% CPU when calculating things like
Sudoku, and you would expect that !
But on my Core 2 Duo desktop, it does not go above 50%,
although it takes CPU on both sides of the processor
(according to the Microsoft standard CPU-meter).
That's an interesting observation: I'm not surprised by it, but it's nice to
have confirmation of what I suspected would be the case.
There are currently very few cases where Saxon uses more than one thread.
One the whole, the benefits don't justify the overhead, especially as I
think the most performance-critical workloads are on a server that is
generally doing many transformations at the same time and therefore has
plenty of opportunities to use multiple processors. But there are cases
where using a dual processor more effectively to improve the latency of a
single batch job would be useful, and it's one of those things I will do
when I get a round tuit.
Michael Kay
http://www.saxonica.com/
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--