You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Sam Ruby <ru...@us.ibm.com> on 2001/04/18 04:14:58 UTC
Timings for processing of small messages
Summary:
Axis and Xerces 2 provide hope for significantly better response time
for small messages then their predecessors.
Disclaimers:
Processing of small messages is not the only scenario, but I would argue
it is an important one. Particularly from the perspective of measuring
overhead. This test is also designed to measure latency (time to send
and receive a request) under rather ideal conditions (one client,
request is completely processed before the next is issued). Other
measurements are important, like throughput (number of messages a server
can process under heavy loads).
These disclaimers aside, this is just the first scenario I have analyzed
in any detail. It is likely to identify areas of fixed overhead, and
any improvement made here will likely benefit all scenarios and will
improve throughput too. I designed these tests unaware of what the
results would be. The tests were not designed to produce a specific
result. I encourage others to reproduce the results. All sources are
attached.
Methodology.
I sent a rather small but syntactically correct soap message, and
generated an appropriate reply. The reply contains data found in the
request, so parsing is required. In the soap and axis cases,
conversions to and from floating point were done, in all others the data
was simply copied as is. In each case, the results were verified using
the TcpTunnelGui tool. The number of request/response pairs were
counted in periods of eleven seconds each, with the first second
ignored. Each test was repeated five times, with the best time taken.
As a general rule, timings improved each time, a phenomenon I attribute
to hotspot. The messages were designed so that they could be processed
by MS dot net beta 1, the Apache xml-soap, and the Apache xml-axis
implementations. All tests were performed with the latest versions of
each of the products compiled from source from CVS within the last 24
hours.
The standard message was:
<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="
http://www.w3.org/1999/XMLSchema-instance" xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<soap:Body>
<echoFloat xmlns="http://tempuri.org/">
<input xsi:type="xsd:float">3.14159</input>
</echoFloat>
</soap:Body>
</soap:Envelope>
With a response of:
<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="
http://www.w3.org/1999/XMLSchema-instance" xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<soap:Body>
<echoFloatResult xmlns="http://tempuri.org/">
<result>3.14159</result>
</echoFloatResult>
</soap:Body>
</soap:Envelope>
Overall results:
The xml-soap implementation processed 50.8 messages at the end, whereas
xml-axis was able to process 93.7 messages per second. This translates
to 19,685 microseconds per message for xml-soap, and 10,672 microseconds
per message for xml-axis.
Both results are based on the Xerces 1 DOM implementation and Tomcat
3.3. The overhead per message for each have been computed at 5,533
microseconds and 3,548 microseconds respectively - the latter number
includes wait time for the client. Subtracting out this fixed cost
results in an overhead of 10,604 microseconds per message for xml-soap
and 1,591 microseconds per message for xml-axis.
Parser overhead:
Alternatives to Xerces 1's implementation of DOM (5533 usec) include
JDOM (5224 usec), Crimson (1789 usec), and Xerces 2 (801 usec). It is
worth repeating - these measurements are based on repeatedly parsing
small messages in the context of a web server; performance of other
scenarios may differ.
Alternatives to DOM is SAX. Measurements were 3,050 usec for Xerces 1,
1,583 usec for Crimson, and 690 usec for Xerces 2.
With Xerces 2, a native interface is available. Timings were 621 usec
for the standard configuration, and 531 usec for the non-validating
configuration.
Two non-parser implementations were also created - one was based on
strings, the other was based on byte arrays. The byte array version was
faster by 163 usec. Hopefully this kind of data can be used to identify
techniques to target in order to further optimize the soap and axis
implementations.
Configuration:
550 Mhz Pentium III
196M RAM
Sun JDK 1.3 w/hotspot
Win2K server
- Sam Ruby
(See attached file: echosoap.zip)
Re: Timings for processing of small messages
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
graham glass wrote:
> hi guys,
>
> incidentally, the Electric XML 1.4 library for parsing
> and manipulating XML was just released, with almost double
> the performance of version 1.3.
>
> Electric XML 1.4 takes about 0.3 milliseconds to parse
> a standard small SOAP message similar to the one that
> sam posted. the benchmark sample i used is here:
>
> http://www.themindelectric.com/products/xml/benchmarks.html
>
> GLUE uses Electric XML/HTTP/servlets and currently
> gets around 550 SOAP messages/second round trip using
> HTTP 1.1 keep alive connections. i think the production
> release should be able to achieve better performance,
> maybe 800 messages/second.
i think that it is only meaningful when compared in exactly the same
environment.
could you add electric xml to tests that are already in echosoap? it would be
very interesting ot see how it compares with other parsers (you would need just
to add two new files and to modify *.bat file as i did with XPP in
http://www.extreme.indiana.edu/~aslom/echosoap/).
thanks,
alek
--
Aleksander Slominski, LH 316, IU, http://www.extreme.indiana.edu/~aslom
As I look afar I see neither cherry Nor tinted leaves Just a modest hut
on the coast In the dusk of Autumn nightfall - Fujiwara no Teika(1162-1241)
Re: Timings for processing of small messages
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
graham glass wrote:
> hi guys,
>
> incidentally, the Electric XML 1.4 library for parsing
> and manipulating XML was just released, with almost double
> the performance of version 1.3.
>
> Electric XML 1.4 takes about 0.3 milliseconds to parse
> a standard small SOAP message similar to the one that
> sam posted. the benchmark sample i used is here:
>
> http://www.themindelectric.com/products/xml/benchmarks.html
>
> GLUE uses Electric XML/HTTP/servlets and currently
> gets around 550 SOAP messages/second round trip using
> HTTP 1.1 keep alive connections. i think the production
> release should be able to achieve better performance,
> maybe 800 messages/second.
i think that it is only meaningful when compared in exactly the same
environment.
could you add electric xml to tests that are already in echosoap? it would be
very interesting ot see how it compares with other parsers (you would need just
to add two new files and to modify *.bat file as i did with XPP in
http://www.extreme.indiana.edu/~aslom/echosoap/).
thanks,
alek
--
Aleksander Slominski, LH 316, IU, http://www.extreme.indiana.edu/~aslom
As I look afar I see neither cherry Nor tinted leaves Just a modest hut
on the coast In the dusk of Autumn nightfall - Fujiwara no Teika(1162-1241)
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: Timings for processing of small messages
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
graham glass wrote:
> hi guys,
>
> incidentally, the Electric XML 1.4 library for parsing
> and manipulating XML was just released, with almost double
> the performance of version 1.3.
>
> Electric XML 1.4 takes about 0.3 milliseconds to parse
> a standard small SOAP message similar to the one that
> sam posted. the benchmark sample i used is here:
>
> http://www.themindelectric.com/products/xml/benchmarks.html
>
> GLUE uses Electric XML/HTTP/servlets and currently
> gets around 550 SOAP messages/second round trip using
> HTTP 1.1 keep alive connections. i think the production
> release should be able to achieve better performance,
> maybe 800 messages/second.
i think that it is only meaningful when compared in exactly the same
environment.
could you add electric xml to tests that are already in echosoap? it would be
very interesting ot see how it compares with other parsers (you would need just
to add two new files and to modify *.bat file as i did with XPP in
http://www.extreme.indiana.edu/~aslom/echosoap/).
thanks,
alek
--
Aleksander Slominski, LH 316, IU, http://www.extreme.indiana.edu/~aslom
As I look afar I see neither cherry Nor tinted leaves Just a modest hut
on the coast In the dusk of Autumn nightfall - Fujiwara no Teika(1162-1241)
RE: Timings for processing of small messages
Posted by graham glass <gr...@mindspring.com>.
hi guys,
incidentally, the Electric XML 1.4 library for parsing
and manipulating XML was just released, with almost double
the performance of version 1.3.
Electric XML 1.4 takes about 0.3 milliseconds to parse
a standard small SOAP message similar to the one that
sam posted. the benchmark sample i used is here:
http://www.themindelectric.com/products/xml/benchmarks.html
GLUE uses Electric XML/HTTP/servlets and currently
gets around 550 SOAP messages/second round trip using
HTTP 1.1 keep alive connections. i think the production
release should be able to achieve better performance,
maybe 800 messages/second.
cheers,
graham
-----Original Message-----
From: Aleksander Slominski [mailto:aslom@cs.indiana.edu]
Sent: Wednesday, April 18, 2001 2:41 AM
To: axis-dev@xml.apache.org
Cc: soap-dev@xml.apache.org; xerces-j-dev@xml.apache.org
Subject: Re: Timings for processing of small messages
Sam Ruby wrote:
> Summary:
>
> Axis and Xerces 2 provide hope for significantly better response time
> for small messages then their predecessors.
hi,
i have re-run your tests and added new tests for Xml Pull Parser (modified
test sources are available at
http://www.extreme.indiana.edu/~aslom/echosoap/).
> Parser overhead:
>
> Alternatives to Xerces 1's implementation of DOM (5533 usec) include
> JDOM (5224 usec), Crimson (1789 usec), and Xerces 2 (801 usec). It is
> worth repeating - these measurements are based on repeatedly parsing
> small messages in the context of a web server; performance of other
> scenarios may differ.
>
> Alternatives to DOM is SAX. Measurements were 3,050 usec for Xerces 1,
> 1,583 usec for Crimson, and 690 usec for Xerces 2.
>
> With Xerces 2, a native interface is available. Timings were 621 usec
> for the standard configuration, and 531 usec for the non-validating
> configuration.
>
> Two non-parser implementations were also created - one was based on
> strings, the other was based on byte arrays. The byte array version
was
> faster by 163 usec. Hopefully this kind of data can be used to
identify
> techniques to target in order to further optimize the soap and axis
> implementations.
i have got different results (though following your patter)
here are my observations: there is following hierarchy (as measured by
number of messages per second):
#messages per second/#microseconds per message test_name(s)
108/9200 jdom, dom1 (from xerces1.3.0)
150/6500 sax1 (from xerces1.3.0)
255/3900 dom2 (from xerces2)
260/3740 sax2
277/3600 xnin, xnis (internal xerces2 interfaces)
300/3300 char, xpp (Xml Pull Parser 1.1)
330/3030 byte
i think that tests should be re-evaluated as from it one could infer that
XPP is fast as reading characters directing from input and it seems not
right :-)
i am suspecting that tests are spending too much time doing buffering and
memory IO including socket connection and disconnection that heavily
affects performance - it would be interesting to see tests that uses HTTP
keep-alive and allows for streaming of input into parsers (and not
buffering it). however it requires very careful coding that will not
introduce unnecessary buffering and delays...( it would be also interesting
to do some testing with chunked encoding but this is even more
difficult...).
(...) The xml-soap implementation processed 50.8 messages at the end,
whereas
xml-axis was able to process 93.7 messages per second. This translates
to 19,685 microseconds per message for xml-soap, and 10,672 microseconds
per message for xml-axis.
Both results are based on the Xerces 1 DOM implementation and Tomcat
3.3. The overhead per message for each have been computed at 5,533
microseconds and 3,548 microseconds respectively - the latter number
includes wait time for the client. Subtracting out this fixed cost
results in an overhead of 10,604 microseconds per message for xml-soap
and 1,591 microseconds per message for xml-axis.(...)
that seems like extremely good result :-)
i have run also servlet tests (without soap and axis but just dom, sax and
xpp) but the results here are extremely inconclusive - i was using
tomcat 3.2.1 and during all tests (sax, dome, xpp and xpp2sax which is SAX
1.0 driver on top of XML Pull Parser) cpu utilization was below 50%!
that means that there are very significant delays somewhere in tomcat IO (i
guess) affecting heavily servlet performance (in tests they are 20x
slower - from 250+ messages per second when standalone to 15-17 messages per
second in servlet).
i could not get any good conclusion from tests - calculating overhead it
would seem that char test is _maximum_ performance that parser can
possible achieve (as it is just converting to UNICODE from byte input
stream and it must be done in any XML parser) so then i could conclude that
XPP _is_ getting this maximum performance but i think it is possible to
achieve even better performance when streaming input into parser...
let me know what you think about it.
thanks,
alek
ps. tests were executed on PII450Mhz/256MB RAM. with Windows 2000 SP1 on
java -version:
java version "1.3.1-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-beta-b15)
Java HotSpot(TM) Client VM (build 1.3.1beta-b15, mixed mode)
and here are actual results:
byte 342.3 2921.0
byte 330.0 3030.0
byte 326.3 3064.0
byte 329.4 3035.0
byte 319.5 3129.0
char 288.4 3467.0
char 297.6 3360.0
char 301.7 3314.0
char 303.3 3297.0
char 304.5 3284.0
sax1 140.2 7132.0
sax1 150.4 6648.0
sax1 153.0 6535.0
sax1 152.6 6553.0
sax1 148.2 6747.0
dom1 96.3 10384.0
dom1 102.3 9775.0
dom1 105.5 9478.0
dom1 105.4 9487.0
dom1 105.3 9496.0
sax2 241.6 4139.0
sax2 267.3 3741.0
sax2 266.9 3746.0
sax2 267.3 3741.0
sax2 267.3 3741.0
dom2 224.3 4458.0
dom2 255.7 3910.0
dom2 256.1 3904.0
dom2 257.8 3878.0
dom2 256.1 3904.0
jdom 83.8 11933.0
jdom 102.7 9737.0
jdom 107.7 9285.0
jdom 108.2 9242.0
jdom 104.5 9569.0
xnin 253.7 3941.0
xnin 278.0 3597.0
xnin 277.5 3603.0
xnin 278.6 3589.0
xnin 277.5 3603.0
xnis 248.6 4022.0
xnis 272.7 3667.0
xnis 274.1 3648.0
xnis 272.6 3668.0
xnis 273.6 3654.0
xpp 290.0 3448.0
xpp 299.0 3344.0
xpp 301.7 3314.0
xpp 300.8 3324.0
xpp 301.4 3317.0
echo/xpp 17.7 56497.0
echo/xpp 16.9 59171.0
echo/xpp 17.7 56497.0
echo/xpp 17.7 56497.0
echo/xpp 17.8 56179.0
echo/xpp2sax 17.7 56497.0
echo/xpp2sax 17.6 56818.0
echo/xpp2sax 17.6 56818.0
echo/xpp2sax 17.6 56818.0
echo/xpp2sax 17.8 56179.0
echo/sax 16.6 60240.0
echo/sax 16.3 61349.0
echo/sax 16.6 60240.0
echo/sax 16.3 61349.0
echo/sax 16.6 60240.0
echo/dom 15.2 65789.0
echo/dom 15.2 65789.0
echo/dom 14.6 68493.0
echo/dom 15.0 66666.0
echo/dom 15.0 66666.0
--
Aleksander Slominski, LH 316, IU, http://www.extreme.indiana.edu/~aslom
As I look afar I see neither cherry Nor tinted leaves Just a modest hut
on the coast In the dusk of Autumn nightfall - Fujiwara no Teika(1162-1241)
RE: Timings for processing of small messages
Posted by graham glass <gr...@mindspring.com>.
hi guys,
incidentally, the Electric XML 1.4 library for parsing
and manipulating XML was just released, with almost double
the performance of version 1.3.
Electric XML 1.4 takes about 0.3 milliseconds to parse
a standard small SOAP message similar to the one that
sam posted. the benchmark sample i used is here:
http://www.themindelectric.com/products/xml/benchmarks.html
GLUE uses Electric XML/HTTP/servlets and currently
gets around 550 SOAP messages/second round trip using
HTTP 1.1 keep alive connections. i think the production
release should be able to achieve better performance,
maybe 800 messages/second.
cheers,
graham
-----Original Message-----
From: Aleksander Slominski [mailto:aslom@cs.indiana.edu]
Sent: Wednesday, April 18, 2001 2:41 AM
To: axis-dev@xml.apache.org
Cc: soap-dev@xml.apache.org; xerces-j-dev@xml.apache.org
Subject: Re: Timings for processing of small messages
Sam Ruby wrote:
> Summary:
>
> Axis and Xerces 2 provide hope for significantly better response time
> for small messages then their predecessors.
hi,
i have re-run your tests and added new tests for Xml Pull Parser (modified
test sources are available at
http://www.extreme.indiana.edu/~aslom/echosoap/).
> Parser overhead:
>
> Alternatives to Xerces 1's implementation of DOM (5533 usec) include
> JDOM (5224 usec), Crimson (1789 usec), and Xerces 2 (801 usec). It is
> worth repeating - these measurements are based on repeatedly parsing
> small messages in the context of a web server; performance of other
> scenarios may differ.
>
> Alternatives to DOM is SAX. Measurements were 3,050 usec for Xerces 1,
> 1,583 usec for Crimson, and 690 usec for Xerces 2.
>
> With Xerces 2, a native interface is available. Timings were 621 usec
> for the standard configuration, and 531 usec for the non-validating
> configuration.
>
> Two non-parser implementations were also created - one was based on
> strings, the other was based on byte arrays. The byte array version
was
> faster by 163 usec. Hopefully this kind of data can be used to
identify
> techniques to target in order to further optimize the soap and axis
> implementations.
i have got different results (though following your patter)
here are my observations: there is following hierarchy (as measured by
number of messages per second):
#messages per second/#microseconds per message test_name(s)
108/9200 jdom, dom1 (from xerces1.3.0)
150/6500 sax1 (from xerces1.3.0)
255/3900 dom2 (from xerces2)
260/3740 sax2
277/3600 xnin, xnis (internal xerces2 interfaces)
300/3300 char, xpp (Xml Pull Parser 1.1)
330/3030 byte
i think that tests should be re-evaluated as from it one could infer that
XPP is fast as reading characters directing from input and it seems not
right :-)
i am suspecting that tests are spending too much time doing buffering and
memory IO including socket connection and disconnection that heavily
affects performance - it would be interesting to see tests that uses HTTP
keep-alive and allows for streaming of input into parsers (and not
buffering it). however it requires very careful coding that will not
introduce unnecessary buffering and delays...( it would be also interesting
to do some testing with chunked encoding but this is even more
difficult...).
(...) The xml-soap implementation processed 50.8 messages at the end,
whereas
xml-axis was able to process 93.7 messages per second. This translates
to 19,685 microseconds per message for xml-soap, and 10,672 microseconds
per message for xml-axis.
Both results are based on the Xerces 1 DOM implementation and Tomcat
3.3. The overhead per message for each have been computed at 5,533
microseconds and 3,548 microseconds respectively - the latter number
includes wait time for the client. Subtracting out this fixed cost
results in an overhead of 10,604 microseconds per message for xml-soap
and 1,591 microseconds per message for xml-axis.(...)
that seems like extremely good result :-)
i have run also servlet tests (without soap and axis but just dom, sax and
xpp) but the results here are extremely inconclusive - i was using
tomcat 3.2.1 and during all tests (sax, dome, xpp and xpp2sax which is SAX
1.0 driver on top of XML Pull Parser) cpu utilization was below 50%!
that means that there are very significant delays somewhere in tomcat IO (i
guess) affecting heavily servlet performance (in tests they are 20x
slower - from 250+ messages per second when standalone to 15-17 messages per
second in servlet).
i could not get any good conclusion from tests - calculating overhead it
would seem that char test is _maximum_ performance that parser can
possible achieve (as it is just converting to UNICODE from byte input
stream and it must be done in any XML parser) so then i could conclude that
XPP _is_ getting this maximum performance but i think it is possible to
achieve even better performance when streaming input into parser...
let me know what you think about it.
thanks,
alek
ps. tests were executed on PII450Mhz/256MB RAM. with Windows 2000 SP1 on
java -version:
java version "1.3.1-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-beta-b15)
Java HotSpot(TM) Client VM (build 1.3.1beta-b15, mixed mode)
and here are actual results:
byte 342.3 2921.0
byte 330.0 3030.0
byte 326.3 3064.0
byte 329.4 3035.0
byte 319.5 3129.0
char 288.4 3467.0
char 297.6 3360.0
char 301.7 3314.0
char 303.3 3297.0
char 304.5 3284.0
sax1 140.2 7132.0
sax1 150.4 6648.0
sax1 153.0 6535.0
sax1 152.6 6553.0
sax1 148.2 6747.0
dom1 96.3 10384.0
dom1 102.3 9775.0
dom1 105.5 9478.0
dom1 105.4 9487.0
dom1 105.3 9496.0
sax2 241.6 4139.0
sax2 267.3 3741.0
sax2 266.9 3746.0
sax2 267.3 3741.0
sax2 267.3 3741.0
dom2 224.3 4458.0
dom2 255.7 3910.0
dom2 256.1 3904.0
dom2 257.8 3878.0
dom2 256.1 3904.0
jdom 83.8 11933.0
jdom 102.7 9737.0
jdom 107.7 9285.0
jdom 108.2 9242.0
jdom 104.5 9569.0
xnin 253.7 3941.0
xnin 278.0 3597.0
xnin 277.5 3603.0
xnin 278.6 3589.0
xnin 277.5 3603.0
xnis 248.6 4022.0
xnis 272.7 3667.0
xnis 274.1 3648.0
xnis 272.6 3668.0
xnis 273.6 3654.0
xpp 290.0 3448.0
xpp 299.0 3344.0
xpp 301.7 3314.0
xpp 300.8 3324.0
xpp 301.4 3317.0
echo/xpp 17.7 56497.0
echo/xpp 16.9 59171.0
echo/xpp 17.7 56497.0
echo/xpp 17.7 56497.0
echo/xpp 17.8 56179.0
echo/xpp2sax 17.7 56497.0
echo/xpp2sax 17.6 56818.0
echo/xpp2sax 17.6 56818.0
echo/xpp2sax 17.6 56818.0
echo/xpp2sax 17.8 56179.0
echo/sax 16.6 60240.0
echo/sax 16.3 61349.0
echo/sax 16.6 60240.0
echo/sax 16.3 61349.0
echo/sax 16.6 60240.0
echo/dom 15.2 65789.0
echo/dom 15.2 65789.0
echo/dom 14.6 68493.0
echo/dom 15.0 66666.0
echo/dom 15.0 66666.0
--
Aleksander Slominski, LH 316, IU, http://www.extreme.indiana.edu/~aslom
As I look afar I see neither cherry Nor tinted leaves Just a modest hut
on the coast In the dusk of Autumn nightfall - Fujiwara no Teika(1162-1241)
RE: Timings for processing of small messages
Posted by graham glass <gr...@mindspring.com>.
hi guys,
incidentally, the Electric XML 1.4 library for parsing
and manipulating XML was just released, with almost double
the performance of version 1.3.
Electric XML 1.4 takes about 0.3 milliseconds to parse
a standard small SOAP message similar to the one that
sam posted. the benchmark sample i used is here:
http://www.themindelectric.com/products/xml/benchmarks.html
GLUE uses Electric XML/HTTP/servlets and currently
gets around 550 SOAP messages/second round trip using
HTTP 1.1 keep alive connections. i think the production
release should be able to achieve better performance,
maybe 800 messages/second.
cheers,
graham
-----Original Message-----
From: Aleksander Slominski [mailto:aslom@cs.indiana.edu]
Sent: Wednesday, April 18, 2001 2:41 AM
To: axis-dev@xml.apache.org
Cc: soap-dev@xml.apache.org; xerces-j-dev@xml.apache.org
Subject: Re: Timings for processing of small messages
Sam Ruby wrote:
> Summary:
>
> Axis and Xerces 2 provide hope for significantly better response time
> for small messages then their predecessors.
hi,
i have re-run your tests and added new tests for Xml Pull Parser (modified
test sources are available at
http://www.extreme.indiana.edu/~aslom/echosoap/).
> Parser overhead:
>
> Alternatives to Xerces 1's implementation of DOM (5533 usec) include
> JDOM (5224 usec), Crimson (1789 usec), and Xerces 2 (801 usec). It is
> worth repeating - these measurements are based on repeatedly parsing
> small messages in the context of a web server; performance of other
> scenarios may differ.
>
> Alternatives to DOM is SAX. Measurements were 3,050 usec for Xerces 1,
> 1,583 usec for Crimson, and 690 usec for Xerces 2.
>
> With Xerces 2, a native interface is available. Timings were 621 usec
> for the standard configuration, and 531 usec for the non-validating
> configuration.
>
> Two non-parser implementations were also created - one was based on
> strings, the other was based on byte arrays. The byte array version
was
> faster by 163 usec. Hopefully this kind of data can be used to
identify
> techniques to target in order to further optimize the soap and axis
> implementations.
i have got different results (though following your patter)
here are my observations: there is following hierarchy (as measured by
number of messages per second):
#messages per second/#microseconds per message test_name(s)
108/9200 jdom, dom1 (from xerces1.3.0)
150/6500 sax1 (from xerces1.3.0)
255/3900 dom2 (from xerces2)
260/3740 sax2
277/3600 xnin, xnis (internal xerces2 interfaces)
300/3300 char, xpp (Xml Pull Parser 1.1)
330/3030 byte
i think that tests should be re-evaluated as from it one could infer that
XPP is fast as reading characters directing from input and it seems not
right :-)
i am suspecting that tests are spending too much time doing buffering and
memory IO including socket connection and disconnection that heavily
affects performance - it would be interesting to see tests that uses HTTP
keep-alive and allows for streaming of input into parsers (and not
buffering it). however it requires very careful coding that will not
introduce unnecessary buffering and delays...( it would be also interesting
to do some testing with chunked encoding but this is even more
difficult...).
(...) The xml-soap implementation processed 50.8 messages at the end,
whereas
xml-axis was able to process 93.7 messages per second. This translates
to 19,685 microseconds per message for xml-soap, and 10,672 microseconds
per message for xml-axis.
Both results are based on the Xerces 1 DOM implementation and Tomcat
3.3. The overhead per message for each have been computed at 5,533
microseconds and 3,548 microseconds respectively - the latter number
includes wait time for the client. Subtracting out this fixed cost
results in an overhead of 10,604 microseconds per message for xml-soap
and 1,591 microseconds per message for xml-axis.(...)
that seems like extremely good result :-)
i have run also servlet tests (without soap and axis but just dom, sax and
xpp) but the results here are extremely inconclusive - i was using
tomcat 3.2.1 and during all tests (sax, dome, xpp and xpp2sax which is SAX
1.0 driver on top of XML Pull Parser) cpu utilization was below 50%!
that means that there are very significant delays somewhere in tomcat IO (i
guess) affecting heavily servlet performance (in tests they are 20x
slower - from 250+ messages per second when standalone to 15-17 messages per
second in servlet).
i could not get any good conclusion from tests - calculating overhead it
would seem that char test is _maximum_ performance that parser can
possible achieve (as it is just converting to UNICODE from byte input
stream and it must be done in any XML parser) so then i could conclude that
XPP _is_ getting this maximum performance but i think it is possible to
achieve even better performance when streaming input into parser...
let me know what you think about it.
thanks,
alek
ps. tests were executed on PII450Mhz/256MB RAM. with Windows 2000 SP1 on
java -version:
java version "1.3.1-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-beta-b15)
Java HotSpot(TM) Client VM (build 1.3.1beta-b15, mixed mode)
and here are actual results:
byte 342.3 2921.0
byte 330.0 3030.0
byte 326.3 3064.0
byte 329.4 3035.0
byte 319.5 3129.0
char 288.4 3467.0
char 297.6 3360.0
char 301.7 3314.0
char 303.3 3297.0
char 304.5 3284.0
sax1 140.2 7132.0
sax1 150.4 6648.0
sax1 153.0 6535.0
sax1 152.6 6553.0
sax1 148.2 6747.0
dom1 96.3 10384.0
dom1 102.3 9775.0
dom1 105.5 9478.0
dom1 105.4 9487.0
dom1 105.3 9496.0
sax2 241.6 4139.0
sax2 267.3 3741.0
sax2 266.9 3746.0
sax2 267.3 3741.0
sax2 267.3 3741.0
dom2 224.3 4458.0
dom2 255.7 3910.0
dom2 256.1 3904.0
dom2 257.8 3878.0
dom2 256.1 3904.0
jdom 83.8 11933.0
jdom 102.7 9737.0
jdom 107.7 9285.0
jdom 108.2 9242.0
jdom 104.5 9569.0
xnin 253.7 3941.0
xnin 278.0 3597.0
xnin 277.5 3603.0
xnin 278.6 3589.0
xnin 277.5 3603.0
xnis 248.6 4022.0
xnis 272.7 3667.0
xnis 274.1 3648.0
xnis 272.6 3668.0
xnis 273.6 3654.0
xpp 290.0 3448.0
xpp 299.0 3344.0
xpp 301.7 3314.0
xpp 300.8 3324.0
xpp 301.4 3317.0
echo/xpp 17.7 56497.0
echo/xpp 16.9 59171.0
echo/xpp 17.7 56497.0
echo/xpp 17.7 56497.0
echo/xpp 17.8 56179.0
echo/xpp2sax 17.7 56497.0
echo/xpp2sax 17.6 56818.0
echo/xpp2sax 17.6 56818.0
echo/xpp2sax 17.6 56818.0
echo/xpp2sax 17.8 56179.0
echo/sax 16.6 60240.0
echo/sax 16.3 61349.0
echo/sax 16.6 60240.0
echo/sax 16.3 61349.0
echo/sax 16.6 60240.0
echo/dom 15.2 65789.0
echo/dom 15.2 65789.0
echo/dom 14.6 68493.0
echo/dom 15.0 66666.0
echo/dom 15.0 66666.0
--
Aleksander Slominski, LH 316, IU, http://www.extreme.indiana.edu/~aslom
As I look afar I see neither cherry Nor tinted leaves Just a modest hut
on the coast In the dusk of Autumn nightfall - Fujiwara no Teika(1162-1241)
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: Timings for processing of small messages
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Sam Ruby wrote:
> Summary:
>
> Axis and Xerces 2 provide hope for significantly better response time
> for small messages then their predecessors.
hi,
i have re-run your tests and added new tests for Xml Pull Parser (modified test sources are available at
http://www.extreme.indiana.edu/~aslom/echosoap/).
> Parser overhead:
>
> Alternatives to Xerces 1's implementation of DOM (5533 usec) include
> JDOM (5224 usec), Crimson (1789 usec), and Xerces 2 (801 usec). It is
> worth repeating - these measurements are based on repeatedly parsing
> small messages in the context of a web server; performance of other
> scenarios may differ.
>
> Alternatives to DOM is SAX. Measurements were 3,050 usec for Xerces 1,
> 1,583 usec for Crimson, and 690 usec for Xerces 2.
>
> With Xerces 2, a native interface is available. Timings were 621 usec
> for the standard configuration, and 531 usec for the non-validating
> configuration.
>
> Two non-parser implementations were also created - one was based on
> strings, the other was based on byte arrays. The byte array version was
> faster by 163 usec. Hopefully this kind of data can be used to identify
> techniques to target in order to further optimize the soap and axis
> implementations.
i have got different results (though following your patter)
here are my observations: there is following hierarchy (as measured by number of messages per second):
#messages per second/#microseconds per message test_name(s)
108/9200 jdom, dom1 (from xerces1.3.0)
150/6500 sax1 (from xerces1.3.0)
255/3900 dom2 (from xerces2)
260/3740 sax2
277/3600 xnin, xnis (internal xerces2 interfaces)
300/3300 char, xpp (Xml Pull Parser 1.1)
330/3030 byte
i think that tests should be re-evaluated as from it one could infer that XPP is fast as reading characters directing from input and it seems not
right :-)
i am suspecting that tests are spending too much time doing buffering and memory IO including socket connection and disconnection that heavily
affects performance - it would be interesting to see tests that uses HTTP keep-alive and allows for streaming of input into parsers (and not
buffering it). however it requires very careful coding that will not introduce unnecessary buffering and delays...( it would be also interesting
to do some testing with chunked encoding but this is even more difficult...).
(...) The xml-soap implementation processed 50.8 messages at the end, whereas
xml-axis was able to process 93.7 messages per second. This translates
to 19,685 microseconds per message for xml-soap, and 10,672 microseconds
per message for xml-axis.
Both results are based on the Xerces 1 DOM implementation and Tomcat
3.3. The overhead per message for each have been computed at 5,533
microseconds and 3,548 microseconds respectively - the latter number
includes wait time for the client. Subtracting out this fixed cost
results in an overhead of 10,604 microseconds per message for xml-soap
and 1,591 microseconds per message for xml-axis.(...)
that seems like extremely good result :-)
i have run also servlet tests (without soap and axis but just dom, sax and xpp) but the results here are extremely inconclusive - i was using
tomcat 3.2.1 and during all tests (sax, dome, xpp and xpp2sax which is SAX 1.0 driver on top of XML Pull Parser) cpu utilization was below 50%!
that means that there are very significant delays somewhere in tomcat IO (i guess) affecting heavily servlet performance (in tests they are 20x
slower - from 250+ messages per second when standalone to 15-17 messages per second in servlet).
i could not get any good conclusion from tests - calculating overhead it would seem that char test is _maximum_ performance that parser can
possible achieve (as it is just converting to UNICODE from byte input stream and it must be done in any XML parser) so then i could conclude that
XPP _is_ getting this maximum performance but i think it is possible to achieve even better performance when streaming input into parser...
let me know what you think about it.
thanks,
alek
ps. tests were executed on PII450Mhz/256MB RAM. with Windows 2000 SP1 on java -version:
java version "1.3.1-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-beta-b15)
Java HotSpot(TM) Client VM (build 1.3.1beta-b15, mixed mode)
and here are actual results:
byte 342.3 2921.0
byte 330.0 3030.0
byte 326.3 3064.0
byte 329.4 3035.0
byte 319.5 3129.0
char 288.4 3467.0
char 297.6 3360.0
char 301.7 3314.0
char 303.3 3297.0
char 304.5 3284.0
sax1 140.2 7132.0
sax1 150.4 6648.0
sax1 153.0 6535.0
sax1 152.6 6553.0
sax1 148.2 6747.0
dom1 96.3 10384.0
dom1 102.3 9775.0
dom1 105.5 9478.0
dom1 105.4 9487.0
dom1 105.3 9496.0
sax2 241.6 4139.0
sax2 267.3 3741.0
sax2 266.9 3746.0
sax2 267.3 3741.0
sax2 267.3 3741.0
dom2 224.3 4458.0
dom2 255.7 3910.0
dom2 256.1 3904.0
dom2 257.8 3878.0
dom2 256.1 3904.0
jdom 83.8 11933.0
jdom 102.7 9737.0
jdom 107.7 9285.0
jdom 108.2 9242.0
jdom 104.5 9569.0
xnin 253.7 3941.0
xnin 278.0 3597.0
xnin 277.5 3603.0
xnin 278.6 3589.0
xnin 277.5 3603.0
xnis 248.6 4022.0
xnis 272.7 3667.0
xnis 274.1 3648.0
xnis 272.6 3668.0
xnis 273.6 3654.0
xpp 290.0 3448.0
xpp 299.0 3344.0
xpp 301.7 3314.0
xpp 300.8 3324.0
xpp 301.4 3317.0
echo/xpp 17.7 56497.0
echo/xpp 16.9 59171.0
echo/xpp 17.7 56497.0
echo/xpp 17.7 56497.0
echo/xpp 17.8 56179.0
echo/xpp2sax 17.7 56497.0
echo/xpp2sax 17.6 56818.0
echo/xpp2sax 17.6 56818.0
echo/xpp2sax 17.6 56818.0
echo/xpp2sax 17.8 56179.0
echo/sax 16.6 60240.0
echo/sax 16.3 61349.0
echo/sax 16.6 60240.0
echo/sax 16.3 61349.0
echo/sax 16.6 60240.0
echo/dom 15.2 65789.0
echo/dom 15.2 65789.0
echo/dom 14.6 68493.0
echo/dom 15.0 66666.0
echo/dom 15.0 66666.0
--
Aleksander Slominski, LH 316, IU, http://www.extreme.indiana.edu/~aslom
As I look afar I see neither cherry Nor tinted leaves Just a modest hut
on the coast In the dusk of Autumn nightfall - Fujiwara no Teika(1162-1241)
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: Timings for processing of small messages
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Sam Ruby wrote:
> Summary:
>
> Axis and Xerces 2 provide hope for significantly better response time
> for small messages then their predecessors.
hi,
i have re-run your tests and added new tests for Xml Pull Parser (modified test sources are available at
http://www.extreme.indiana.edu/~aslom/echosoap/).
> Parser overhead:
>
> Alternatives to Xerces 1's implementation of DOM (5533 usec) include
> JDOM (5224 usec), Crimson (1789 usec), and Xerces 2 (801 usec). It is
> worth repeating - these measurements are based on repeatedly parsing
> small messages in the context of a web server; performance of other
> scenarios may differ.
>
> Alternatives to DOM is SAX. Measurements were 3,050 usec for Xerces 1,
> 1,583 usec for Crimson, and 690 usec for Xerces 2.
>
> With Xerces 2, a native interface is available. Timings were 621 usec
> for the standard configuration, and 531 usec for the non-validating
> configuration.
>
> Two non-parser implementations were also created - one was based on
> strings, the other was based on byte arrays. The byte array version was
> faster by 163 usec. Hopefully this kind of data can be used to identify
> techniques to target in order to further optimize the soap and axis
> implementations.
i have got different results (though following your patter)
here are my observations: there is following hierarchy (as measured by number of messages per second):
#messages per second/#microseconds per message test_name(s)
108/9200 jdom, dom1 (from xerces1.3.0)
150/6500 sax1 (from xerces1.3.0)
255/3900 dom2 (from xerces2)
260/3740 sax2
277/3600 xnin, xnis (internal xerces2 interfaces)
300/3300 char, xpp (Xml Pull Parser 1.1)
330/3030 byte
i think that tests should be re-evaluated as from it one could infer that XPP is fast as reading characters directing from input and it seems not
right :-)
i am suspecting that tests are spending too much time doing buffering and memory IO including socket connection and disconnection that heavily
affects performance - it would be interesting to see tests that uses HTTP keep-alive and allows for streaming of input into parsers (and not
buffering it). however it requires very careful coding that will not introduce unnecessary buffering and delays...( it would be also interesting
to do some testing with chunked encoding but this is even more difficult...).
(...) The xml-soap implementation processed 50.8 messages at the end, whereas
xml-axis was able to process 93.7 messages per second. This translates
to 19,685 microseconds per message for xml-soap, and 10,672 microseconds
per message for xml-axis.
Both results are based on the Xerces 1 DOM implementation and Tomcat
3.3. The overhead per message for each have been computed at 5,533
microseconds and 3,548 microseconds respectively - the latter number
includes wait time for the client. Subtracting out this fixed cost
results in an overhead of 10,604 microseconds per message for xml-soap
and 1,591 microseconds per message for xml-axis.(...)
that seems like extremely good result :-)
i have run also servlet tests (without soap and axis but just dom, sax and xpp) but the results here are extremely inconclusive - i was using
tomcat 3.2.1 and during all tests (sax, dome, xpp and xpp2sax which is SAX 1.0 driver on top of XML Pull Parser) cpu utilization was below 50%!
that means that there are very significant delays somewhere in tomcat IO (i guess) affecting heavily servlet performance (in tests they are 20x
slower - from 250+ messages per second when standalone to 15-17 messages per second in servlet).
i could not get any good conclusion from tests - calculating overhead it would seem that char test is _maximum_ performance that parser can
possible achieve (as it is just converting to UNICODE from byte input stream and it must be done in any XML parser) so then i could conclude that
XPP _is_ getting this maximum performance but i think it is possible to achieve even better performance when streaming input into parser...
let me know what you think about it.
thanks,
alek
ps. tests were executed on PII450Mhz/256MB RAM. with Windows 2000 SP1 on java -version:
java version "1.3.1-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-beta-b15)
Java HotSpot(TM) Client VM (build 1.3.1beta-b15, mixed mode)
and here are actual results:
byte 342.3 2921.0
byte 330.0 3030.0
byte 326.3 3064.0
byte 329.4 3035.0
byte 319.5 3129.0
char 288.4 3467.0
char 297.6 3360.0
char 301.7 3314.0
char 303.3 3297.0
char 304.5 3284.0
sax1 140.2 7132.0
sax1 150.4 6648.0
sax1 153.0 6535.0
sax1 152.6 6553.0
sax1 148.2 6747.0
dom1 96.3 10384.0
dom1 102.3 9775.0
dom1 105.5 9478.0
dom1 105.4 9487.0
dom1 105.3 9496.0
sax2 241.6 4139.0
sax2 267.3 3741.0
sax2 266.9 3746.0
sax2 267.3 3741.0
sax2 267.3 3741.0
dom2 224.3 4458.0
dom2 255.7 3910.0
dom2 256.1 3904.0
dom2 257.8 3878.0
dom2 256.1 3904.0
jdom 83.8 11933.0
jdom 102.7 9737.0
jdom 107.7 9285.0
jdom 108.2 9242.0
jdom 104.5 9569.0
xnin 253.7 3941.0
xnin 278.0 3597.0
xnin 277.5 3603.0
xnin 278.6 3589.0
xnin 277.5 3603.0
xnis 248.6 4022.0
xnis 272.7 3667.0
xnis 274.1 3648.0
xnis 272.6 3668.0
xnis 273.6 3654.0
xpp 290.0 3448.0
xpp 299.0 3344.0
xpp 301.7 3314.0
xpp 300.8 3324.0
xpp 301.4 3317.0
echo/xpp 17.7 56497.0
echo/xpp 16.9 59171.0
echo/xpp 17.7 56497.0
echo/xpp 17.7 56497.0
echo/xpp 17.8 56179.0
echo/xpp2sax 17.7 56497.0
echo/xpp2sax 17.6 56818.0
echo/xpp2sax 17.6 56818.0
echo/xpp2sax 17.6 56818.0
echo/xpp2sax 17.8 56179.0
echo/sax 16.6 60240.0
echo/sax 16.3 61349.0
echo/sax 16.6 60240.0
echo/sax 16.3 61349.0
echo/sax 16.6 60240.0
echo/dom 15.2 65789.0
echo/dom 15.2 65789.0
echo/dom 14.6 68493.0
echo/dom 15.0 66666.0
echo/dom 15.0 66666.0
--
Aleksander Slominski, LH 316, IU, http://www.extreme.indiana.edu/~aslom
As I look afar I see neither cherry Nor tinted leaves Just a modest hut
on the coast In the dusk of Autumn nightfall - Fujiwara no Teika(1162-1241)
Re: Timings for processing of small messages
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Sam Ruby wrote:
> Summary:
>
> Axis and Xerces 2 provide hope for significantly better response time
> for small messages then their predecessors.
hi,
i have re-run your tests and added new tests for Xml Pull Parser (modified test sources are available at
http://www.extreme.indiana.edu/~aslom/echosoap/).
> Parser overhead:
>
> Alternatives to Xerces 1's implementation of DOM (5533 usec) include
> JDOM (5224 usec), Crimson (1789 usec), and Xerces 2 (801 usec). It is
> worth repeating - these measurements are based on repeatedly parsing
> small messages in the context of a web server; performance of other
> scenarios may differ.
>
> Alternatives to DOM is SAX. Measurements were 3,050 usec for Xerces 1,
> 1,583 usec for Crimson, and 690 usec for Xerces 2.
>
> With Xerces 2, a native interface is available. Timings were 621 usec
> for the standard configuration, and 531 usec for the non-validating
> configuration.
>
> Two non-parser implementations were also created - one was based on
> strings, the other was based on byte arrays. The byte array version was
> faster by 163 usec. Hopefully this kind of data can be used to identify
> techniques to target in order to further optimize the soap and axis
> implementations.
i have got different results (though following your patter)
here are my observations: there is following hierarchy (as measured by number of messages per second):
#messages per second/#microseconds per message test_name(s)
108/9200 jdom, dom1 (from xerces1.3.0)
150/6500 sax1 (from xerces1.3.0)
255/3900 dom2 (from xerces2)
260/3740 sax2
277/3600 xnin, xnis (internal xerces2 interfaces)
300/3300 char, xpp (Xml Pull Parser 1.1)
330/3030 byte
i think that tests should be re-evaluated as from it one could infer that XPP is fast as reading characters directing from input and it seems not
right :-)
i am suspecting that tests are spending too much time doing buffering and memory IO including socket connection and disconnection that heavily
affects performance - it would be interesting to see tests that uses HTTP keep-alive and allows for streaming of input into parsers (and not
buffering it). however it requires very careful coding that will not introduce unnecessary buffering and delays...( it would be also interesting
to do some testing with chunked encoding but this is even more difficult...).
(...) The xml-soap implementation processed 50.8 messages at the end, whereas
xml-axis was able to process 93.7 messages per second. This translates
to 19,685 microseconds per message for xml-soap, and 10,672 microseconds
per message for xml-axis.
Both results are based on the Xerces 1 DOM implementation and Tomcat
3.3. The overhead per message for each have been computed at 5,533
microseconds and 3,548 microseconds respectively - the latter number
includes wait time for the client. Subtracting out this fixed cost
results in an overhead of 10,604 microseconds per message for xml-soap
and 1,591 microseconds per message for xml-axis.(...)
that seems like extremely good result :-)
i have run also servlet tests (without soap and axis but just dom, sax and xpp) but the results here are extremely inconclusive - i was using
tomcat 3.2.1 and during all tests (sax, dome, xpp and xpp2sax which is SAX 1.0 driver on top of XML Pull Parser) cpu utilization was below 50%!
that means that there are very significant delays somewhere in tomcat IO (i guess) affecting heavily servlet performance (in tests they are 20x
slower - from 250+ messages per second when standalone to 15-17 messages per second in servlet).
i could not get any good conclusion from tests - calculating overhead it would seem that char test is _maximum_ performance that parser can
possible achieve (as it is just converting to UNICODE from byte input stream and it must be done in any XML parser) so then i could conclude that
XPP _is_ getting this maximum performance but i think it is possible to achieve even better performance when streaming input into parser...
let me know what you think about it.
thanks,
alek
ps. tests were executed on PII450Mhz/256MB RAM. with Windows 2000 SP1 on java -version:
java version "1.3.1-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-beta-b15)
Java HotSpot(TM) Client VM (build 1.3.1beta-b15, mixed mode)
and here are actual results:
byte 342.3 2921.0
byte 330.0 3030.0
byte 326.3 3064.0
byte 329.4 3035.0
byte 319.5 3129.0
char 288.4 3467.0
char 297.6 3360.0
char 301.7 3314.0
char 303.3 3297.0
char 304.5 3284.0
sax1 140.2 7132.0
sax1 150.4 6648.0
sax1 153.0 6535.0
sax1 152.6 6553.0
sax1 148.2 6747.0
dom1 96.3 10384.0
dom1 102.3 9775.0
dom1 105.5 9478.0
dom1 105.4 9487.0
dom1 105.3 9496.0
sax2 241.6 4139.0
sax2 267.3 3741.0
sax2 266.9 3746.0
sax2 267.3 3741.0
sax2 267.3 3741.0
dom2 224.3 4458.0
dom2 255.7 3910.0
dom2 256.1 3904.0
dom2 257.8 3878.0
dom2 256.1 3904.0
jdom 83.8 11933.0
jdom 102.7 9737.0
jdom 107.7 9285.0
jdom 108.2 9242.0
jdom 104.5 9569.0
xnin 253.7 3941.0
xnin 278.0 3597.0
xnin 277.5 3603.0
xnin 278.6 3589.0
xnin 277.5 3603.0
xnis 248.6 4022.0
xnis 272.7 3667.0
xnis 274.1 3648.0
xnis 272.6 3668.0
xnis 273.6 3654.0
xpp 290.0 3448.0
xpp 299.0 3344.0
xpp 301.7 3314.0
xpp 300.8 3324.0
xpp 301.4 3317.0
echo/xpp 17.7 56497.0
echo/xpp 16.9 59171.0
echo/xpp 17.7 56497.0
echo/xpp 17.7 56497.0
echo/xpp 17.8 56179.0
echo/xpp2sax 17.7 56497.0
echo/xpp2sax 17.6 56818.0
echo/xpp2sax 17.6 56818.0
echo/xpp2sax 17.6 56818.0
echo/xpp2sax 17.8 56179.0
echo/sax 16.6 60240.0
echo/sax 16.3 61349.0
echo/sax 16.6 60240.0
echo/sax 16.3 61349.0
echo/sax 16.6 60240.0
echo/dom 15.2 65789.0
echo/dom 15.2 65789.0
echo/dom 14.6 68493.0
echo/dom 15.0 66666.0
echo/dom 15.0 66666.0
--
Aleksander Slominski, LH 316, IU, http://www.extreme.indiana.edu/~aslom
As I look afar I see neither cherry Nor tinted leaves Just a modest hut
on the coast In the dusk of Autumn nightfall - Fujiwara no Teika(1162-1241)