You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-users@xerces.apache.org by Andrew Welch <an...@gmail.com> on 2013/11/12 13:48:47 UTC
contention during XMLReaderFactory.createXMLReader
Hi,
A colleague was doing some performance testing and discovered some
contention at this line of my code:
XMLReaderFactory.createXMLReader("org.apache.xerces.parsers.SAXParser");
...which was surprising : ) He informed me it was doing a blocking
operation every time.
Anyway, he went away and went through the Xerces source and found that
if the "org.apache.xerces.xni.parser.XMLParserConfiguration" system
property is not set it does indeed do a blocking operation (in
parsers.ObjectFactory)
To demonstrate this, run the below code with and without the system
property set:
public static void main(String... args) throws Exception {
//System.setProperty("org.apache.xerces.xni.parser.XMLParserConfiguration",
// "org.apache.xerces.parsers.XIncludeParserConfiguration");
long start = System.nanoTime();
for (int i = 0; i <= 10000; i++) {
XMLReaderFactory.createXMLReader("org.apache.xerces.parsers.SAXParser");
}
long end = System.nanoTime();
double millis = (end - start) * 1e-6;
System.out.println(millis);
}
On my machine it consistently takes around ~2000ms without the system
property, and ~1300ms with.
This is present in both 2.9 and 2.11 as far as I can see.
--
Andrew Welch
http://andrewjwelch.com
---------------------------------------------------------------------
To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-users-help@xerces.apache.org
Re: contention during XMLReaderFactory.createXMLReader
Posted by Michael Glavassevich <mr...@ca.ibm.com>.
Hi Andrew,
System properties are global settings. It's not always a good idea to set
them. If you were to set the system property in an application server
where other applications have a preference to use alternate JAXP
implementations you may break them.
Frameworks such as OSGi allow bundles to be loaded/unloaded dynamically
meaning that the "classpath" which the ClassLoader searches over can
change over time. It may return a different implementation or another
version of the same implementation depending on when you invoke
XMLReaderFactory.createXMLReader().
Thanks.
Michael Glavassevich
XML Technologies and WAS Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org
Andrew Welch <an...@gmail.com> wrote on 11/13/2013 06:10:12 AM:
> Hi again,
>
> Out of interest - what's the reason for not setting the system
> property after doing the META-INF search? At the moment every jar
> file gets examined every time an XMLReader is created - is there a
> situation where users want different results from subsequent calls to
> createXMLReader("...") controlled purely by the classpath?
>
> With that system property set, it's really fast to create XMLReaders...
>
>
> On 12 November 2013 19:18, Michael Glavassevich <mr...@ca.ibm.com>
wrote:
> > Hi Andrew,
> >
> > Creating a new XML parser can be very expensive. The ClassLoader used
to
> > create the parser and its internal components might block or spend a
long
> > time searching its "classpath" for META-INF/services files. This is
why
> > it's generally a good idea to cache and reuse [1] XML parser
instances.
> >
> > Thanks.
> >
> > [1]
> >
http://www.ibm.com/developerworks/xml/library/x-perfap2/index.html#reuse
> >
> > Michael Glavassevich
> > XML Technologies and WAS Development
> > IBM Toronto Lab
> > E-mail: mrglavas@ca.ibm.com
> > E-mail: mrglavas@apache.org
> >
> > Andrew Welch <an...@gmail.com> wrote on 11/12/2013 07:48:47
AM:
> >
> >> Hi,
> >>
> >> A colleague was doing some performance testing and discovered some
> >> contention at this line of my code:
> >>
> >>
XMLReaderFactory.createXMLReader("org.apache.xerces.parsers.SAXParser");
> >>
> >> ...which was surprising : ) He informed me it was doing a blocking
> >> operation every time.
> >>
> >> Anyway, he went away and went through the Xerces source and found
that
> >> if the "org.apache.xerces.xni.parser.XMLParserConfiguration" system
> >> property is not set it does indeed do a blocking operation (in
> >> parsers.ObjectFactory)
> >>
> >> To demonstrate this, run the below code with and without the system
> >> property set:
> >>
> >> public static void main(String... args) throws Exception {
> >>
> >> //System.setProperty
> >> ("org.apache.xerces.xni.parser.XMLParserConfiguration",
> >> // "org.apache.xerces.parsers.XIncludeParserConfiguration");
> >>
> >> long start = System.nanoTime();
> >>
> >> for (int i = 0; i <= 10000; i++) {
> >> XMLReaderFactory.createXMLReader
> >> ("org.apache.xerces.parsers.SAXParser");
> >> }
> >>
> >> long end = System.nanoTime();
> >> double millis = (end - start) * 1e-6;
> >>
> >> System.out.println(millis);
> >>
> >> }
> >>
> >> On my machine it consistently takes around ~2000ms without the system
> >> property, and ~1300ms with.
> >>
> >> This is present in both 2.9 and 2.11 as far as I can see.
> >>
> >>
> >>
> >>
> >> --
> >> Andrew Welch
> >> http://andrewjwelch.com
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
> >> For additional commands, e-mail: j-users-help@xerces.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
> > For additional commands, e-mail: j-users-help@xerces.apache.org
> >
>
>
>
> --
> Andrew Welch
> http://andrewjwelch.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
> For additional commands, e-mail: j-users-help@xerces.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-users-help@xerces.apache.org
Re: contention during XMLReaderFactory.createXMLReader
Posted by Andrew Welch <an...@gmail.com>.
Hi again,
Out of interest - what's the reason for not setting the system
property after doing the META-INF search? At the moment every jar
file gets examined every time an XMLReader is created - is there a
situation where users want different results from subsequent calls to
createXMLReader("...") controlled purely by the classpath?
With that system property set, it's really fast to create XMLReaders...
On 12 November 2013 19:18, Michael Glavassevich <mr...@ca.ibm.com> wrote:
> Hi Andrew,
>
> Creating a new XML parser can be very expensive. The ClassLoader used to
> create the parser and its internal components might block or spend a long
> time searching its "classpath" for META-INF/services files. This is why
> it's generally a good idea to cache and reuse [1] XML parser instances.
>
> Thanks.
>
> [1]
> http://www.ibm.com/developerworks/xml/library/x-perfap2/index.html#reuse
>
> Michael Glavassevich
> XML Technologies and WAS Development
> IBM Toronto Lab
> E-mail: mrglavas@ca.ibm.com
> E-mail: mrglavas@apache.org
>
> Andrew Welch <an...@gmail.com> wrote on 11/12/2013 07:48:47 AM:
>
>> Hi,
>>
>> A colleague was doing some performance testing and discovered some
>> contention at this line of my code:
>>
>> XMLReaderFactory.createXMLReader("org.apache.xerces.parsers.SAXParser");
>>
>> ...which was surprising : ) He informed me it was doing a blocking
>> operation every time.
>>
>> Anyway, he went away and went through the Xerces source and found that
>> if the "org.apache.xerces.xni.parser.XMLParserConfiguration" system
>> property is not set it does indeed do a blocking operation (in
>> parsers.ObjectFactory)
>>
>> To demonstrate this, run the below code with and without the system
>> property set:
>>
>> public static void main(String... args) throws Exception {
>>
>> //System.setProperty
>> ("org.apache.xerces.xni.parser.XMLParserConfiguration",
>> // "org.apache.xerces.parsers.XIncludeParserConfiguration");
>>
>> long start = System.nanoTime();
>>
>> for (int i = 0; i <= 10000; i++) {
>> XMLReaderFactory.createXMLReader
>> ("org.apache.xerces.parsers.SAXParser");
>> }
>>
>> long end = System.nanoTime();
>> double millis = (end - start) * 1e-6;
>>
>> System.out.println(millis);
>>
>> }
>>
>> On my machine it consistently takes around ~2000ms without the system
>> property, and ~1300ms with.
>>
>> This is present in both 2.9 and 2.11 as far as I can see.
>>
>>
>>
>>
>> --
>> Andrew Welch
>> http://andrewjwelch.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
>> For additional commands, e-mail: j-users-help@xerces.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
> For additional commands, e-mail: j-users-help@xerces.apache.org
>
--
Andrew Welch
http://andrewjwelch.com
---------------------------------------------------------------------
To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-users-help@xerces.apache.org
Re: contention during XMLReaderFactory.createXMLReader
Posted by Andrew Welch <an...@gmail.com>.
"One of the common misconceptions about writing XML applications is
that creating a parser instance does not incur a large performance
cost. "
Thanks Michael, I was under that common misconception.
I'll tell my colleague that he does need to pool the parsers after all.
cheers
andrew
On 12 November 2013 19:18, Michael Glavassevich <mr...@ca.ibm.com> wrote:
> Hi Andrew,
>
> Creating a new XML parser can be very expensive. The ClassLoader used to
> create the parser and its internal components might block or spend a long
> time searching its "classpath" for META-INF/services files. This is why
> it's generally a good idea to cache and reuse [1] XML parser instances.
>
> Thanks.
>
> [1]
> http://www.ibm.com/developerworks/xml/library/x-perfap2/index.html#reuse
>
> Michael Glavassevich
> XML Technologies and WAS Development
> IBM Toronto Lab
> E-mail: mrglavas@ca.ibm.com
> E-mail: mrglavas@apache.org
>
> Andrew Welch <an...@gmail.com> wrote on 11/12/2013 07:48:47 AM:
>
>> Hi,
>>
>> A colleague was doing some performance testing and discovered some
>> contention at this line of my code:
>>
>> XMLReaderFactory.createXMLReader("org.apache.xerces.parsers.SAXParser");
>>
>> ...which was surprising : ) He informed me it was doing a blocking
>> operation every time.
>>
>> Anyway, he went away and went through the Xerces source and found that
>> if the "org.apache.xerces.xni.parser.XMLParserConfiguration" system
>> property is not set it does indeed do a blocking operation (in
>> parsers.ObjectFactory)
>>
>> To demonstrate this, run the below code with and without the system
>> property set:
>>
>> public static void main(String... args) throws Exception {
>>
>> //System.setProperty
>> ("org.apache.xerces.xni.parser.XMLParserConfiguration",
>> // "org.apache.xerces.parsers.XIncludeParserConfiguration");
>>
>> long start = System.nanoTime();
>>
>> for (int i = 0; i <= 10000; i++) {
>> XMLReaderFactory.createXMLReader
>> ("org.apache.xerces.parsers.SAXParser");
>> }
>>
>> long end = System.nanoTime();
>> double millis = (end - start) * 1e-6;
>>
>> System.out.println(millis);
>>
>> }
>>
>> On my machine it consistently takes around ~2000ms without the system
>> property, and ~1300ms with.
>>
>> This is present in both 2.9 and 2.11 as far as I can see.
>>
>>
>>
>>
>> --
>> Andrew Welch
>> http://andrewjwelch.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
>> For additional commands, e-mail: j-users-help@xerces.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
> For additional commands, e-mail: j-users-help@xerces.apache.org
>
--
Andrew Welch
http://andrewjwelch.com
---------------------------------------------------------------------
To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-users-help@xerces.apache.org
Re: contention during XMLReaderFactory.createXMLReader
Posted by Michael Glavassevich <mr...@ca.ibm.com>.
Hi Andrew,
Creating a new XML parser can be very expensive. The ClassLoader used to
create the parser and its internal components might block or spend a long
time searching its "classpath" for META-INF/services files. This is why
it's generally a good idea to cache and reuse [1] XML parser instances.
Thanks.
[1]
http://www.ibm.com/developerworks/xml/library/x-perfap2/index.html#reuse
Michael Glavassevich
XML Technologies and WAS Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org
Andrew Welch <an...@gmail.com> wrote on 11/12/2013 07:48:47 AM:
> Hi,
>
> A colleague was doing some performance testing and discovered some
> contention at this line of my code:
>
> XMLReaderFactory.createXMLReader("org.apache.xerces.parsers.SAXParser");
>
> ...which was surprising : ) He informed me it was doing a blocking
> operation every time.
>
> Anyway, he went away and went through the Xerces source and found that
> if the "org.apache.xerces.xni.parser.XMLParserConfiguration" system
> property is not set it does indeed do a blocking operation (in
> parsers.ObjectFactory)
>
> To demonstrate this, run the below code with and without the system
> property set:
>
> public static void main(String... args) throws Exception {
>
> //System.setProperty
> ("org.apache.xerces.xni.parser.XMLParserConfiguration",
> // "org.apache.xerces.parsers.XIncludeParserConfiguration");
>
> long start = System.nanoTime();
>
> for (int i = 0; i <= 10000; i++) {
> XMLReaderFactory.createXMLReader
> ("org.apache.xerces.parsers.SAXParser");
> }
>
> long end = System.nanoTime();
> double millis = (end - start) * 1e-6;
>
> System.out.println(millis);
>
> }
>
> On my machine it consistently takes around ~2000ms without the system
> property, and ~1300ms with.
>
> This is present in both 2.9 and 2.11 as far as I can see.
>
>
>
>
> --
> Andrew Welch
> http://andrewjwelch.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
> For additional commands, e-mail: j-users-help@xerces.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-users-help@xerces.apache.org