You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Vadim Gritsenko <va...@verizon.net> on 2002/01/28 03:29:47 UTC
Who needs 386% speed up?
Hi,
While playing with OptimizeIt, I found quite interesting piece of code
in Xalan code, class org.apache.xml.utils.DefaultErrorHandler:
public DefaultErrorHandler()
{
m_pw = new PrintWriter(System.err, true);
}
Which, according to OptimizeIt, takes 42.72% of time on the simple
pipeline with XSP generator and XML serializer (modified /cocoon/sub/xsp
sample, without transformation). This was hard to believe, so I got
Xalan CVS and quickly hacked this class (diff attached). The results are
astonishing: also I did not get much improvement in throughput (too much
time was taken by the sockets; may be more testing threads will help),
but processing time improved on 386%, from 498 ms to 129 ms.
I though somebody might be interested in this result, so here is the
letter :)
PS If somebody could ask Xalan guys to get rid of new PrintWriter() -
this would be great :)
PPS XSPs *are* fast. XSL is slow :-|
Vadim
RE: Who needs 386% speed up?
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Torsten Curdt [mailto:tcurdt@dff.st]
>
> > >>Hi,
> > >>
> > >>I though somebody might be interested in this result, so here is
the
> > >>letter :)
> > >>PS If somebody could ask Xalan guys to get rid of new
PrintWriter() -
> > >>this would be great :)
> > >>
> > >
> > > Did post a message on Xalan Dev?
> >
> >
> > Please do!
>
> Can anyone subscribed to XalanDev do this - otherwise I will go an
> get me subscribed....
I got me subscribed...
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Who needs 386% speed up?
Posted by Torsten Curdt <tc...@dff.st>.
> >>Hi,
> >>
> >>I though somebody might be interested in this result, so here is the
> >>letter :)
> >>PS If somebody could ask Xalan guys to get rid of new PrintWriter() -
> >>this would be great :)
> >>
> >
> > Did post a message on Xalan Dev?
>
>
> Please do!
Can anyone subscribed to XalanDev do this - otherwise I will go an
get me subscribed....
> >>PPS XSPs *are* fast. XSL is slow :-|
> >>
> >
> > ...but people say XSPs are not skaling very good. AFAIR (vaguely) Berin
> > tracked this down (also with optimizeIt) and it was a classloader issue.
> > Berin, is this right? Please correct me if I am wrong... I guess this
> > raised the monitoring thread...
> >
> > (Sorry didn't find the correct message in the archives)
>
>
> It wasn't me who used OptimizeIt, I think it was Sylvain. There are a number
> of issues with XSP, though. Here are a few:
As I said - I vaguely remembered ;)
> 1) Classloader issues. sometimes the XSP system won't let go of the reference
> to the old class, causing the new XSP to be recompiled every time and never
> used. This was fixed when we moved the generated XSP from the root of the
> work directory.
ok
> 2) The wrapping the calls of the XSP to handle "return" calls in the middle of
> a SAX stream. I think we decided to remove this "feature", but I don't recall
> if it was actually done.
Hm.. I guess all we decided was to add a comment to the documentation that
return calls in a XSP page are to be considered *bad*
> 3) Evaluation on whether the XSP is current takes a long time, and incurs
> accessing the filesystem with each request. Making the compiled elements'
> management asynchronous will help in this area.
What about a config option to turn off this checking ?
For developing checking is mandatory but for a life site that does
not change very often this might give us some more speed.
I wouldn't care to turn it on/off for changes...
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Who needs 386% speed up?
Posted by Berin Loritsch <bl...@apache.org>.
Torsten Curdt wrote:
> On Sun, 27 Jan 2002, Vadim Gritsenko wrote:
>
>
>>Hi,
>>
>>I though somebody might be interested in this result, so here is the
>>letter :)
>>PS If somebody could ask Xalan guys to get rid of new PrintWriter() -
>>this would be great :)
>>
>
> Did post a message on Xalan Dev?
Please do!
>>PPS XSPs *are* fast. XSL is slow :-|
>>
>
> ...but people say XSPs are not skaling very good. AFAIR (vaguely) Berin
> tracked this down (also with optimizeIt) and it was a classloader issue.
> Berin, is this right? Please correct me if I am wrong... I guess this
> raised the monitoring thread...
>
> (Sorry didn't find the correct message in the archives)
It wasn't me who used OptimizeIt, I think it was Sylvain. There are a number
of issues with XSP, though. Here are a few:
1) Classloader issues. sometimes the XSP system won't let go of the reference
to the old class, causing the new XSP to be recompiled every time and never
used. This was fixed when we moved the generated XSP from the root of the
work directory.
2) The wrapping the calls of the XSP to handle "return" calls in the middle of
a SAX stream. I think we decided to remove this "feature", but I don't recall
if it was actually done.
3) Evaluation on whether the XSP is current takes a long time, and incurs
accessing the filesystem with each request. Making the compiled elements'
management asynchronous will help in this area.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Who needs 386% speed up?
Posted by Paulo Gaspar <pa...@krankikom.de>.
> There are cases where LinkedList has good performances (mainly
> insert/remove in the middle of the list), but it's the slowest for stacks.
That is a less absolute statement. I was missing that context.
=:o)
For stacks the ArrayList is obviously faster as soon as maximum
length is reached.
Have fun,
Paulo
> -----Original Message-----
> From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
> Sent: Monday, January 28, 2002 4:01 PM
>
>
> Paulo Gaspar wrote:
>
> >>-----Original Message-----
> >>From: Berin Loritsch [mailto:bloritsch@apache.org]
> >>Sent: Monday, January 28, 2002 3:11 PM
> >>
> >>
> >>LinkedList? That is the slowest list we have!
> >>
> >
> >That really depends on what you are doing.
> >
> >It is not much slower to iterate trough it than any
> >other list and it can obviously be faster to update
> >it than to update an ArrayList.
> >
> >"Thinking in Java" (http://www.mindview.net/Books/TIJ/)
> >had some interesting tables with the result of
> >several comparative performance tests in the 1st
> >edition (I still did not look at the 2nd edition).
> >
> >
> >Have fun,
> >Paulo Gaspar
> >
> There are cases where LinkedList has good performances (mainly
> insert/remove in the middle of the list), but it's the slowest for stacks.
>
> See http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101136593301059&w=2
> for a recent discussion on this subject.
>
> Sylvain
>
> --
> Sylvain Wallez
> Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Who needs 386% speed up?
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Paulo Gaspar wrote:
>>-----Original Message-----
>>From: Berin Loritsch [mailto:bloritsch@apache.org]
>>Sent: Monday, January 28, 2002 3:11 PM
>>
>>
>>LinkedList? That is the slowest list we have!
>>
>
>That really depends on what you are doing.
>
>It is not much slower to iterate trough it than any
>other list and it can obviously be faster to update
>it than to update an ArrayList.
>
>"Thinking in Java" (http://www.mindview.net/Books/TIJ/)
>had some interesting tables with the result of
>several comparative performance tests in the 1st
>edition (I still did not look at the 2nd edition).
>
>
>Have fun,
>Paulo Gaspar
>
There are cases where LinkedList has good performances (mainly
insert/remove in the middle of the list), but it's the slowest for stacks.
See http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101136593301059&w=2
for a recent discussion on this subject.
Sylvain
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Who needs 386% speed up?
Posted by Paulo Gaspar <pa...@krankikom.de>.
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: Monday, January 28, 2002 3:11 PM
>
>
> LinkedList? That is the slowest list we have!
That really depends on what you are doing.
It is not much slower to iterate trough it than any
other list and it can obviously be faster to update
it than to update an ArrayList.
"Thinking in Java" (http://www.mindview.net/Books/TIJ/)
had some interesting tables with the result of
several comparative performance tests in the 1st
edition (I still did not look at the 2nd edition).
Have fun,
Paulo Gaspar
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Who needs 386% speed up?
Posted by Berin Loritsch <bl...@apache.org>.
Sylvain Wallez wrote:
> Torsten Curdt wrote:
>
> ... or is this bad scalability a past myth ? I refactored
> ServerPagesGenerator at the beginning of december to make the
> document-completion stuff faster and optional (disabled by default).
> This was using a LinkedList to keep track of the open XML elements.
LinkedList? That is the slowest list we have!
> For more info, see
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=100739488123738&w=2
>
> The next thing that's needed for XSP to be as fast as a regular
> generator is a way to remove unneeded white space used for indenting in
> the XSP source : about half of produced SAX events are blank strings.
Perhaps we need a "strip whitespace" option on the SAX parser?
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Who needs 386% speed up?
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
>
> Torsten Curdt wrote:
>
> >On Sun, 27 Jan 2002, Vadim Gritsenko wrote:
> >
> >>Hi,
> >>
> >>While playing with OptimizeIt, I found quite interesting piece of
code
> >>in Xalan code, class org.apache.xml.utils.DefaultErrorHandler:
> >>
> >> public DefaultErrorHandler()
> >> {
> >> m_pw = new PrintWriter(System.err, true);
> >> }
> >>
> >So it's the creation of that PrintWriter that takes so long?
Yepp.
> >
> Do you know when is this class used, and why it is instancied so often
?
Used to report an exception. Search shows 8 files. The most important
ones are:
org\apache\xalan\processor\TransformerFactoryImpl.java
org\apache\xalan\transformer\TransformerIdentityImpl.java
org\apache\xalan\transformer\TransformerImpl.java
org\apache\xpath\XPath.java
It is instantiated as often as these classes are instantiated. In
Cocoon, TransformerIdentityImpl is used in every SAX pipeline at least
once.
> >>PS If somebody could ask Xalan guys to get rid of new PrintWriter()
-
> >>this would be great :)
> >>
> >Did post a message on Xalan Dev?
Nope... Yet.
> >>PPS XSPs *are* fast. XSL is slow :-|
> >>
> >...but people say XSPs are not skaling very good. AFAIR (vaguely)
Berin
> >tracked this down (also with optimizeIt) and it was a classloader
issue.
> >Berin, is this right? Please correct me if I am wrong... I guess this
I saw one issue with XSPs & classloaders: Every compilation of XSP
creates a ClassLoader (for obvious reasons), which is not garbage
collected (under OptimizeIt).
> >raised the monitoring thread...
> >
> ... or is this bad scalability a past myth ? I refactored
> ServerPagesGenerator at the beginning of december to make the
> document-completion stuff faster and optional (disabled by default).
> This was using a LinkedList to keep track of the open XML elements.
>
> For more info, see
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=100739488123738&w=2
>
> The next thing that's needed for XSP to be as fast as a regular
> generator is a way to remove unneeded white space used for indenting
in
> the XSP source : about half of produced SAX events are blank strings.
Ok, you already have a volunteer for this. Good luck, John! :)
> Sylvain
>
> --
> Sylvain Wallez
> Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Who needs 386% speed up?
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Torsten Curdt wrote:
>On Sun, 27 Jan 2002, Vadim Gritsenko wrote:
>
>>Hi,
>>
>>While playing with OptimizeIt, I found quite interesting piece of code
>>in Xalan code, class org.apache.xml.utils.DefaultErrorHandler:
>>
>> public DefaultErrorHandler()
>> {
>> m_pw = new PrintWriter(System.err, true);
>> }
>>
>So it's the creation of that PrintWriter that takes so long?
>
Do you know when is this class used, and why it is instancied so often ?
>>Which, according to OptimizeIt, takes 42.72% of time on the simple
>>pipeline with XSP generator and XML serializer (modified /cocoon/sub/xsp
>>sample, without transformation). This was hard to believe, so I got
>>Xalan CVS and quickly hacked this class (diff attached). The results are
>>astonishing: also I did not get much improvement in throughput (too much
>>time was taken by the sockets; may be more testing threads will help),
>>but processing time improved on 386%, from 498 ms to 129 ms.
>>
>>I though somebody might be interested in this result, so here is the
>>letter :)
>>
>Definitly ;)
>
>>PS If somebody could ask Xalan guys to get rid of new PrintWriter() -
>>this would be great :)
>>
>Did post a message on Xalan Dev?
>
>>PPS XSPs *are* fast. XSL is slow :-|
>>
>...but people say XSPs are not skaling very good. AFAIR (vaguely) Berin
>tracked this down (also with optimizeIt) and it was a classloader issue.
>Berin, is this right? Please correct me if I am wrong... I guess this
>raised the monitoring thread...
>
... or is this bad scalability a past myth ? I refactored
ServerPagesGenerator at the beginning of december to make the
document-completion stuff faster and optional (disabled by default).
This was using a LinkedList to keep track of the open XML elements.
For more info, see
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=100739488123738&w=2
The next thing that's needed for XSP to be as fast as a regular
generator is a way to remove unneeded white space used for indenting in
the XSP source : about half of produced SAX events are blank strings.
Sylvain
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Who needs 386% speed up?
Posted by Torsten Curdt <tc...@dff.st>.
On Sun, 27 Jan 2002, Vadim Gritsenko wrote:
> Hi,
>
> While playing with OptimizeIt, I found quite interesting piece of code
> in Xalan code, class org.apache.xml.utils.DefaultErrorHandler:
>
> public DefaultErrorHandler()
> {
> m_pw = new PrintWriter(System.err, true);
> }
So it's the creation of that PrintWriter that takes so long?
> Which, according to OptimizeIt, takes 42.72% of time on the simple
> pipeline with XSP generator and XML serializer (modified /cocoon/sub/xsp
> sample, without transformation). This was hard to believe, so I got
> Xalan CVS and quickly hacked this class (diff attached). The results are
> astonishing: also I did not get much improvement in throughput (too much
> time was taken by the sockets; may be more testing threads will help),
> but processing time improved on 386%, from 498 ms to 129 ms.
>
> I though somebody might be interested in this result, so here is the
> letter :)
Definitly ;)
> PS If somebody could ask Xalan guys to get rid of new PrintWriter() -
> this would be great :)
Did post a message on Xalan Dev?
> PPS XSPs *are* fast. XSL is slow :-|
...but people say XSPs are not skaling very good. AFAIR (vaguely) Berin
tracked this down (also with optimizeIt) and it was a classloader issue.
Berin, is this right? Please correct me if I am wrong... I guess this
raised the monitoring thread...
(Sorry didn't find the correct message in the archives)
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org