Re: contention during XMLReaderFactory.createXMLReader
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: mrgla...@ca.ibm.com E-mail: mrgla...@apache.org Andrew Welch 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 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: mrgla...@ca.ibm.com > > E-mail: mrgla...@apache.org > > > > Andrew Welch 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 <= 1; 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-unsubscr...@xerces.apache.org > >> For additional commands, e-mail: j-users-h...@xerces.apache.org > > > > > > - > > To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org > > For additional commands, e-mail: j-users-h...@xerces.apache.org > > > > > > -- > Andrew Welch > http://andrewjwelch.com > > - > To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org > For additional commands, e-mail: j-users-h...@xerces.apache.org - To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org For additional commands, e-mail: j-users-h...@xerces.apache.org
Re: contention during XMLReaderFactory.createXMLReader
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 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: mrgla...@ca.ibm.com > E-mail: mrgla...@apache.org > > Andrew Welch 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 <= 1; 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-unsubscr...@xerces.apache.org >> For additional commands, e-mail: j-users-h...@xerces.apache.org > > > - > To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org > For additional commands, e-mail: j-users-h...@xerces.apache.org > -- Andrew Welch http://andrewjwelch.com - To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org For additional commands, e-mail: j-users-h...@xerces.apache.org
Re: contention during XMLReaderFactory.createXMLReader
"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 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: mrgla...@ca.ibm.com > E-mail: mrgla...@apache.org > > Andrew Welch 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 <= 1; 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-unsubscr...@xerces.apache.org >> For additional commands, e-mail: j-users-h...@xerces.apache.org > > > - > To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org > For additional commands, e-mail: j-users-h...@xerces.apache.org > -- Andrew Welch http://andrewjwelch.com - To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org For additional commands, e-mail: j-users-h...@xerces.apache.org
Re: contention during XMLReaderFactory.createXMLReader
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: mrgla...@ca.ibm.com E-mail: mrgla...@apache.org Andrew Welch 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 <= 1; 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-unsubscr...@xerces.apache.org > For additional commands, e-mail: j-users-h...@xerces.apache.org - To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org For additional commands, e-mail: j-users-h...@xerces.apache.org
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 <= 1; 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-unsubscr...@xerces.apache.org For additional commands, e-mail: j-users-h...@xerces.apache.org