RE: [ubl-lcsc] ERRATA! Processing Efficiency Test WASRe:PositionPaper on List Containers

["A Gregory" <agregory@aeon-llc.com>]

Stephen:

I just sent you a long reply, but didn't want to spam the list. The
short answer is: the XPaths have to change to accommodate the containers
for the test to mean anything.

But I would say that from the stuff we've done here (running a single
scenario a few times), and having reached opposite conclusions, its
clear we don't know much of anything. (Which was a point raised earlier,
anyway.)

If I can find the time I will try to do some slightly-more-serious tests
with Xalan as well as a production version of Saxon (which,
incidentally, Michael Kay says Instant Saxon is not). (If I do, you'll
hear from me, but it would mean I couldn't go fishing this weekend, so I
have to say it's pretty unlikely... ;-)  )

Cheers,

Arofan

-----Original Message-----
From: Stephen Green [mailto:stephen_green@bristol-city.gov.uk] 
Sent: Tuesday, September 02, 2003 3:51 AM
To: agregory@aeon-llc.com; cheekai@softml.net
Cc: ubl-lcsc@lists.oasis-open.org; abcoates@londonmarketsystems.com;
tmcgrath@portcomm.com.au
Subject: RE: [ubl-lcsc] ERRATA! Processing Efficiency Test
WASRe:PositionPaper on List Containers

Arofan

Am I getting it wrong still? I had interpreted your thesis to be that
containers relieve the burden on a processor (parser or the like) of
holding in memory those parts of a document which it doesn't need, if
the relevant parts are held in a list and that this results in
performance improvements.

What I have demonstrated is:

A) The margin for error is shown in the output I obtained to be about 50
in 500 (i.e. +/- 10%) 

B) Having a container in a part of the instance which is not being
addressed with the XPath does not improve performance in handling those
parts, outside of that container, that are addressed in the XPath

I think these two findings are particularly relevant in the testing of
the thesis
(A) seems to me to swallow up your benefits of 10% improvement in any
case
(B) shows that if there were to be an improvement it would have to
happen when an XPath *includes* the container in some way.

I'd like, time permitting to further examine this last point and the
tests I did were in my view necessary preliminaries.

To justify further testing I think we need first to consider point (A).
Can you demonstate any improvements beyond the evident margin of error?

All the best

Steve

>>> "A Gregory" <agregory@aeon-llc.com> 02/09/03 10:54:22 >>>
Stephen:

I have a question to ask (I ran into this yesterday in my own tests):

Did you remember to edit the XSL transformation to accommodate the
containers? I noticed you have the same XSL file for all tests. 

The difference between having a match or not having any skews the
comparison (and although we're not using the same version of saxon, I'm
surprised that I got different results...)

Cheers,

Arofan
-----Original Message-----
From: Stephen Green [mailto:stephen_green@bristol-city.gov.uk] 
Sent: Tuesday, September 02, 2003 1:14 AM
To: agregory@aeon-llc.com; cheekai@softml.net 
Cc: ubl-lcsc@lists.oasis-open.org; abcoates@londonmarketsystems.com;
tmcgrath@portcomm.com.au 
Subject: [ubl-lcsc] ERRATA! Processing Efficiency Test WAS
Re:PositionPaper on List Containers

IMPORTANT CORRECTION
--------------------------------

Sorry folks but I'll have to quickly retract my previous finding about
list containers

Tim pointed out that there was adifference in sizes between my two files
(my excuse - trying to do more than time allows again)

***   The results I obtained before were solely due to a editing error
***

When I corrected this  ** There was no difference in the times of
processing **


Thanks Tim for a timely correction. 
Sincere apologies for this misleading error. 
I'm glad I included the two test files with the last message.

The erroneous file was the test1.xml file - somehow dragging and
dropping the lines into the InvoiceLineList lost all but 167 of the
lines.
The output I now get with 1000 line (on a different machine mind) is

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\ubltest\test>saxon -t test.xml test.xsl
SAXON 6.5.3 from Michael Kay
Java version 1.1.4
Preparation time: 188 milliseconds
Processing file:/C:/ubltest/test/test.xml
Building tree for file:/C:/ubltest/test/test.xml using class
com.icl.saxon.tinyt
ree.TinyBuilder
Tree built in 422 milliseconds
<html>
   <head>
      <meta http-equiv="Content-Type" content="text/html;
charset=utf-8">
   </head>
   <body></body>
</html>Execution time: 500 milliseconds

C:\ubltest\test>saxon -t test1.xml test.xsl
SAXON 6.5.3 from Michael Kay
Java version 1.1.4
Preparation time: 187 milliseconds
Processing file:/C:/ubltest/test/test1.xml
Building tree for file:/C:/ubltest/test/test1.xml using class
com.icl.saxon.tiny
tree.TinyBuilder
Tree built in 485 milliseconds
<html>
   <head>
      <meta http-equiv="Content-Type" content="text/html;
charset=utf-8">
   </head>
   <body></body>
</html>Execution time: 547 milliseconds

C:\ubltest\test>saxon -t test.xml test.xsl
SAXON 6.5.3 from Michael Kay
Java version 1.1.4
Preparation time: 188 milliseconds
Processing file:/C:/ubltest/test/test.xml
Building tree for file:/C:/ubltest/test/test.xml using class
com.icl.saxon.tinyt
ree.TinyBuilder
Tree built in 422 milliseconds
<html>
   <head>
      <meta http-equiv="Content-Type" content="text/html;
charset=utf-8">
   </head>
   <body></body>
</html>Execution time: 500 milliseconds

C:\ubltest\test>saxon -t test1.xml test.xsl
SAXON 6.5.3 from Michael Kay
Java version 1.1.4
Preparation time: 188 milliseconds
Processing file:/C:/ubltest/test/test1.xml
Building tree for file:/C:/ubltest/test/test1.xml using class
com.icl.saxon.tiny
tree.TinyBuilder
Tree built in 437 milliseconds
<html>
   <head>
      <meta http-equiv="Content-Type" content="text/html;
charset=utf-8">
   </head>
   <body></body>
</html>Execution time: 500 milliseconds

C:\ubltest\test>