Michael,

To practice use of type validation, I decided to see if made any difference if the elements in the data set were validated as integers or not. I may not have done this properly, but I did not see any improvement.

I realize you did not guarantee any improvement from this, but I also want to make sure I'm doing this right. If I may impose on your good will, could you see if I did this properly?

Here are the changes I made:
A. I added <<default-validation="preserve">> to the xsl:stylesheet tag. I don't think this is actually necessary.

B. I declared an inline schema as:

    <xsl:import-schema>
        <xs:schema>
        <xs:element name="point" type="data-point"/>
        <xs:complexType name="data-point">
            <xs:attribute name="x" type="xs:integer"/>
            <xs:attribute name="ys" type="xs:integer"/>
            <xs:attribute name="yc" type="xs:integer"/>
            <xs:attribute name="yg" type="xs:integer"/>
            <xs:attribute name="z" type="xs:integer"/>   
        </xs:complexType>
        </xs:schema>
    </xsl:import-schema>


C. When loading values into my $data variable, I used <<validate="strict">> as so:

        <xsl:variable name="data" as="schema-element(point)*">
                        <xsl:for-each select="$PaG/student[@user.ID=current()/@user.ID]/point">
                            <xsl:copy-of select="." validation="strict"/>
                        </xsl:for-each>
            </xsl:variable>


D. When indicating parameters for the called template, I declared "$data" as having type point:

<xsl:template name="EPSolver">
        <xsl:param name="simplex"/>
        <xsl:param name="data" as="schema-element(point)*"/>
        <xsl:param name="count"/>
        <xsl:param name="tolerance" as="xs:double"/>


E. Similarly, when calling the template I used "as" to specify the type:





On Sun, Feb 3, 2013 at 5:54 AM, David Rudel <fwqhgads@gmail.com> wrote:
Thanks, Michael, this is very helpful. I spent this evening learning about validation. Perhaps soon I can discontinue the use of writing "$A - $B gt 0" every time I wanted to test "$A gt $B" for numeric variables. :)

I'll probably look into using maps as well once I upgrade oXygen to use Saxon 9.4 natively (I prefer the syntax/implementation of maps in Saxon 9.4 over 9.3).



On Sun, Feb 3, 2013 at 12:59 AM, Michael Kay <mike@saxonica.com> wrote:

On 02/02/2013 22:56, Michael Kay wrote:


I'll have a play with the example and see if I can add any insights.


First experiment: see what the impact of bytecode generation is. Answer: it brings the runtime down from 19.8s to 17.2, perhaps 15%. That's not untypical, but sometimes with stylesheets dominated by computation the effect is much greater; it suggests the time is dominated by something where bytecode generation has relatively little impact.

Next experiment: switch on Java profiling. This shows the performance dominated by two things: ArrayIterator processing, which is presumably the repeated iteration over the elements in the data file, and string-to-double conversion.

Next experiment: run with -TP:profile.html. Unfortunately this causes the transformation to fail with a stack overflow. I think that tail-recursion is being suppressed because it makes it impossible to get a useful execution profile.

Another way of saving the repeated string-to-double conversion cost might be to use a memo function: extract the double value of each attribute of the data file using a function declared with saxon:memo-function="yes".

Using tunnel parameters isn't going to help performance. The cost of passing the parameter is negligible; it's the cost of repetitive processing of the data that's the concern. Try passing 5 parameters, each a sequence of xs:double values, rather than a sequence of elements containing these five numbers as attributes.

Michael Kay
Saxonica

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan
_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
saxon-help@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/saxon-help



--

"A false conclusion, once arrived at and widely accepted is not dislodged easily, and the less it is understood, the more tenaciously it is held." - Cantor's Law of Preservation of Ignorance.



--

"A false conclusion, once arrived at and widely accepted is not dislodged easily, and the less it is understood, the more tenaciously it is held." - Cantor's Law of Preservation of Ignorance.