[jira] [Commented] (JXPATH-183) XMLGregorianCalendar existence adding a lot of performance penalty
[
https://issues.apache.org/jira/browse/JXPATH-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15030710#comment-15030710
]
Michele Vivoda commented on JXPATH-183:
---
Registering the class as atomic value should be the solution of this issue, the
trick is that one must not register the abstract super class but the
implementation class:
{noformat}
try {
JXPathIntrospector.registerAtomicClass(
DatatypeFactory.newInstance().newXMLGregorianCalendar("2010-02-02").getClass());
} catch (DatatypeConfigurationException e) {
e.printStackTrace();
// ignore, no datatype lib
}
{noformat}
Maybe this should be done in the constructor of {{JXPathIntrospector}} and
probably also for {{GregorianCalendar}}. I noticed also that, after registering
a class as atomic is still possible to access the properties using a "direct"
xpath, for example calendar timezone {{cal/timeZone}}, looks like that the
difference is only in that the properties are not iterable, for example when
using {{cal//*}}
> XMLGregorianCalendar existence adding a lot of performance penalty
> --
>
> Key: JXPATH-183
> URL: https://issues.apache.org/jira/browse/JXPATH-183
> Project: Commons JXPath
> Issue Type: Improvement
>Affects Versions: 1.3
> Environment: Windows 7, Amazon Unix, Weblogic
>Reporter: Ganna Shmatova
> Labels: performance
> Attachments: JXPath183Test.java
>
>
> We're using JXPath to parse some input from a client. When they give us a
> valid date it gets transformed from a SOAP message into Java objects. When
> this happens JXPath queries suddenly take 1-8 seconds more (depending on
> system -- the optimized system it's 1 second, dev & test machines it's 8).
> Kicker is, we don't even look for this field. Just its existence does it.
> (we've quickfixed to omit the xml tags before the string is parsed into Java
> for now)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JXPATH-183) XMLGregorianCalendar existence adding a lot of performance penalty
[ https://issues.apache.org/jira/browse/JXPATH-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15029001#comment-15029001 ] Sebb commented on JXPATH-183: - If the test really is required, it would probably be possible to speed it up a lot by using a binary chop method. > XMLGregorianCalendar existence adding a lot of performance penalty > -- > > Key: JXPATH-183 > URL: https://issues.apache.org/jira/browse/JXPATH-183 > Project: Commons JXPath > Issue Type: Improvement >Affects Versions: 1.3 > Environment: Windows 7, Amazon Unix, Weblogic >Reporter: Ganna Shmatova > Labels: performance > > We're using JXPath to parse some input from a client. When they give us a > valid date it gets transformed from a SOAP message into Java objects. When > this happens JXPath queries suddenly take 1-8 seconds more (depending on > system -- the optimized system it's 1 second, dev & test machines it's 8). > Kicker is, we don't even look for this field. Just its existence does it. > (we've quickfixed to omit the xml tags before the string is parsed into Java > for now) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JXPATH-183) XMLGregorianCalendar existence adding a lot of performance penalty
[
https://issues.apache.org/jira/browse/JXPATH-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15028982#comment-15028982
]
Michele Vivoda commented on JXPATH-183:
---
Not sure why this feature exists, to support [indexed
poperties|http://da2i.univ-lille1.fr/doc/tutorial-java/javabeans/properties/indexed.html]
I think, there is one test about it {{BeanModelTest}}, not sure if there are
use cases for it, for me is a not so common pattern.
I think that guessing in this way is risky as came out from this issue, the
method could have also more side effects than just waiting. If it were for me
I would remove this feature in a next release for the risks it creates, or at
least disable it by default.
> XMLGregorianCalendar existence adding a lot of performance penalty
> --
>
> Key: JXPATH-183
> URL: https://issues.apache.org/jira/browse/JXPATH-183
> Project: Commons JXPath
> Issue Type: Improvement
>Affects Versions: 1.3
> Environment: Windows 7, Amazon Unix, Weblogic
>Reporter: Ganna Shmatova
> Labels: performance
>
> We're using JXPath to parse some input from a client. When they give us a
> valid date it gets transformed from a SOAP message into Java objects. When
> this happens JXPath queries suddenly take 1-8 seconds more (depending on
> system -- the optimized system it's 1 second, dev & test machines it's 8).
> Kicker is, we don't even look for this field. Just its existence does it.
> (we've quickfixed to omit the xml tags before the string is parsed into Java
> for now)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JXPATH-183) XMLGregorianCalendar existence adding a lot of performance penalty
[ https://issues.apache.org/jira/browse/JXPATH-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15028953#comment-15028953 ] Michele Vivoda commented on JXPATH-183: --- Even worse, is calling 16000 times a method with reflection because it expects the method to throw exception if out of bounds. If is the timezone method to be called I know that timezone retrieval can be expensive and that being the int an offset is ok to pass from 0 to 16000. > XMLGregorianCalendar existence adding a lot of performance penalty > -- > > Key: JXPATH-183 > URL: https://issues.apache.org/jira/browse/JXPATH-183 > Project: Commons JXPath > Issue Type: Improvement >Affects Versions: 1.3 > Environment: Windows 7, Amazon Unix, Weblogic >Reporter: Ganna Shmatova > Labels: performance > > We're using JXPath to parse some input from a client. When they give us a > valid date it gets transformed from a SOAP message into Java objects. When > this happens JXPath queries suddenly take 1-8 seconds more (depending on > system -- the optimized system it's 1 second, dev & test machines it's 8). > Kicker is, we don't even look for this field. Just its existence does it. > (we've quickfixed to omit the xml tags before the string is parsed into Java > for now) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JXPATH-183) XMLGregorianCalendar existence adding a lot of performance penalty
[ https://issues.apache.org/jira/browse/JXPATH-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15028951#comment-15028951 ] Michele Vivoda commented on JXPATH-183: --- yes, see JXPATH-186 > XMLGregorianCalendar existence adding a lot of performance penalty > -- > > Key: JXPATH-183 > URL: https://issues.apache.org/jira/browse/JXPATH-183 > Project: Commons JXPath > Issue Type: Improvement >Affects Versions: 1.3 > Environment: Windows 7, Amazon Unix, Weblogic >Reporter: Ganna Shmatova > Labels: performance > > We're using JXPath to parse some input from a client. When they give us a > valid date it gets transformed from a SOAP message into Java objects. When > this happens JXPath queries suddenly take 1-8 seconds more (depending on > system -- the optimized system it's 1 second, dev & test machines it's 8). > Kicker is, we don't even look for this field. Just its existence does it. > (we've quickfixed to omit the xml tags before the string is parsed into Java > for now) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JXPATH-183) XMLGregorianCalendar existence adding a lot of performance penalty
[ https://issues.apache.org/jira/browse/JXPATH-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15028872#comment-15028872 ] Ganna Shmatova commented on JXPATH-183: --- Is in the logs. The expression searches for all instances of LOB. With //LOB. So yes it would probably search there. > XMLGregorianCalendar existence adding a lot of performance penalty > -- > > Key: JXPATH-183 > URL: https://issues.apache.org/jira/browse/JXPATH-183 > Project: Commons JXPath > Issue Type: Improvement >Affects Versions: 1.3 > Environment: Windows 7, Amazon Unix, Weblogic >Reporter: Ganna Shmatova > Labels: performance > > We're using JXPath to parse some input from a client. When they give us a > valid date it gets transformed from a SOAP message into Java objects. When > this happens JXPath queries suddenly take 1-8 seconds more (depending on > system -- the optimized system it's 1 second, dev & test machines it's 8). > Kicker is, we don't even look for this field. Just its existence does it. > (we've quickfixed to omit the xml tags before the string is parsed into Java > for now) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JXPATH-183) XMLGregorianCalendar existence adding a lot of performance penalty
[ https://issues.apache.org/jira/browse/JXPATH-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15028858#comment-15028858 ] Sebb commented on JXPATH-183: - It's also really bad to catch Throwable. > XMLGregorianCalendar existence adding a lot of performance penalty > -- > > Key: JXPATH-183 > URL: https://issues.apache.org/jira/browse/JXPATH-183 > Project: Commons JXPath > Issue Type: Improvement >Affects Versions: 1.3 > Environment: Windows 7, Amazon Unix, Weblogic >Reporter: Ganna Shmatova > Labels: performance > > We're using JXPath to parse some input from a client. When they give us a > valid date it gets transformed from a SOAP message into Java objects. When > this happens JXPath queries suddenly take 1-8 seconds more (depending on > system -- the optimized system it's 1 second, dev & test machines it's 8). > Kicker is, we don't even look for this field. Just its existence does it. > (we've quickfixed to omit the xml tags before the string is parsed into Java > for now) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JXPATH-183) XMLGregorianCalendar existence adding a lot of performance penalty
[
https://issues.apache.org/jira/browse/JXPATH-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15028820#comment-15028820
]
Michael Osipov commented on JXPATH-183:
---
That is a terrible piece of code which creates 16000 new integer objects.
[{{Integer#valueOf}}|http://docs.oracle.com/javase/7/docs/api/java/lang/Integer.html#valueOf%28int%29].
should give a better performance here.
> XMLGregorianCalendar existence adding a lot of performance penalty
> --
>
> Key: JXPATH-183
> URL: https://issues.apache.org/jira/browse/JXPATH-183
> Project: Commons JXPath
> Issue Type: Improvement
>Affects Versions: 1.3
> Environment: Windows 7, Amazon Unix, Weblogic
>Reporter: Ganna Shmatova
> Labels: performance
>
> We're using JXPath to parse some input from a client. When they give us a
> valid date it gets transformed from a SOAP message into Java objects. When
> this happens JXPath queries suddenly take 1-8 seconds more (depending on
> system -- the optimized system it's 1 second, dev & test machines it's 8).
> Kicker is, we don't even look for this field. Just its existence does it.
> (we've quickfixed to omit the xml tags before the string is parsed into Java
> for now)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JXPATH-183) XMLGregorianCalendar existence adding a lot of performance penalty
[
https://issues.apache.org/jira/browse/JXPATH-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15028113#comment-15028113
]
Michele Vivoda commented on JXPATH-183:
---
Hi, I think this is the source of the problem, from
{{ValueUtils.getIndexedPropertyLength()}}, {{UNKNOWN_LENGTH_MAX_COUNT}} is
{{16000}}
{noformat}
for (int i = 0; i < UNKNOWN_LENGTH_MAX_COUNT; i++) {
try {
readMethod.invoke(object, new Integer(i));
}
catch (Throwable t) {
return i;
}
}
{noformat}
The method javadoc says it
bq. guess the length of the collection by calling the indexed get method
repeatedly. The method is supposed to throw an exception if the index is out
of bounds
Not sure why is done in this way, however this method is called only for
properties that are described by {{java.beans.IndexedPropertyDescriptor}}, this
is the case for {{XMLGregorianCalendar.getTimeZone(int)}}, then I don't know
if/how your XPath gets there, can you provide your XPath expression ?
> XMLGregorianCalendar existence adding a lot of performance penalty
> --
>
> Key: JXPATH-183
> URL: https://issues.apache.org/jira/browse/JXPATH-183
> Project: Commons JXPath
> Issue Type: Improvement
>Affects Versions: 1.3
> Environment: Windows 7, Amazon Unix, Weblogic
>Reporter: Ganna Shmatova
> Labels: performance
>
> We're using JXPath to parse some input from a client. When they give us a
> valid date it gets transformed from a SOAP message into Java objects. When
> this happens JXPath queries suddenly take 1-8 seconds more (depending on
> system -- the optimized system it's 1 second, dev & test machines it's 8).
> Kicker is, we don't even look for this field. Just its existence does it.
> (we've quickfixed to omit the xml tags before the string is parsed into Java
> for now)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JXPATH-183) XMLGregorianCalendar existence adding a lot of performance penalty
[
https://issues.apache.org/jira/browse/JXPATH-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15025045#comment-15025045
]
Michael Osipov commented on JXPATH-183:
---
Thanks for this. {{XMLGregorianCalendar}} is nowhere directly used in JXPath.
This is a hard one. I have an idea how we could narrow this down but it will
take some work from your side.
Assuming that you are generating your Java model with JAXB's XJC, you could
create a mapper with converts {{xs:dateTime}} to a Joda class or Java 8 Date
and Time API and you'll see whether it is truly {{XMLGregorianCalendar}} or
rather JXPath.
What do you think?
> XMLGregorianCalendar existence adding a lot of performance penalty
> --
>
> Key: JXPATH-183
> URL: https://issues.apache.org/jira/browse/JXPATH-183
> Project: Commons JXPath
> Issue Type: Improvement
>Affects Versions: 1.3
> Environment: Windows 7, Amazon Unix, Weblogic
>Reporter: Ganna Shmatova
> Labels: performance
>
> We're using JXPath to parse some input from a client. When they give us a
> valid date it gets transformed from a SOAP message into Java objects. When
> this happens JXPath queries suddenly take 1-8 seconds more (depending on
> system -- the optimized system it's 1 second, dev & test machines it's 8).
> Kicker is, we don't even look for this field. Just its existence does it.
> (we've quickfixed to omit the xml tags before the string is parsed into Java
> for now)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JXPATH-183) XMLGregorianCalendar existence adding a lot of performance penalty
[
https://issues.apache.org/jira/browse/JXPATH-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15024894#comment-15024894
]
Ganna Shmatova commented on JXPATH-183:
---
It was discovered in the logs:
{quote}
2015-11-24 11:16:19,928 INFO [[ACTIVE] ExecuteThread: '3' for queue:
'weblogic.kernel.Default (self-tuning)'] (Mapping.java:55) - [sessionID:
perf-test] [] Retrieving from base mapping
//LOB/account/accountIdentifier[type='A']
2015-11-24 11:16:24,056 INFO [[ACTIVE] ExecuteThread: '3' for queue:
'weblogic.kernel.Default (self-tuning)'] (Mapping.java:79) - [sessionID:
perf-test] [] Assigning mapping accountNumber [identifier] = 34256523
2015-11-24 11:16:24,059 INFO [[ACTIVE] ExecuteThread: '3' for queue:
'weblogic.kernel.Default (self-tuning)']
(MappedPreparedSelectStatement.java:54) - [sessionID: H] [] select ID1, ID2
from ACCOUNTS where LOB_ACCOUNT_NO='34256523' and LOB_ACCOUNT_TYPE_NAME='H'
2015-11-24 11:16:24,256 INFO [[ACTIVE] ExecuteThread: '3' for queue:
'weblogic.kernel.Default (self-tuning)'] (AudienceIdRetrieval.java:36) - Query
retrieved 0 records, and grabbed them in the following format:
2015-11-24 11:16:24,257 INFO [[ACTIVE] ExecuteThread: '3' for queue:
'weblogic.kernel.Default (self-tuning)'] (Mapping.java:55) - [sessionID:
perf-test] [] Retrieving from base mapping
//LOB/account/accountIdentifier[type='C']
2015-11-24 11:16:27,240 WARN [[ACTIVE] ExecuteThread: '3' for queue:
'weblogic.kernel.Default (self-tuning)'] (Mapping.java:84) - [sessionID:
perf-test] [] Base mapping [//LOB/account/accountIdentifier[type='C']] not
found
2015-11-24 11:16:27,242 WARN [[ACTIVE] ExecuteThread: '3' for queue:
'weblogic.kernel.Default (self-tuning)'] (MappingRetrieval.java:96) -
[sessionID: perf-test] [] Query [select ID1, ID2 from ACCOUNTS where
LOB_ACCOUNT_NO={accountNumber} and LOB_ACCOUNT_TYPE_NAME={accountType}] will
not be run because mapping [origin] could not be found
2015-11-24 11:16:27,242 INFO [[ACTIVE] ExecuteThread: '3' for queue:
'weblogic.kernel.Default (self-tuning)'] (Mapping.java:55) - [sessionID:
perf-test] [] Retrieving from base mapping
//LOB/account/accountIdentifier[type='B']
2015-11-24 11:16:30,167 WARN [[ACTIVE] ExecuteThread: '3' for queue:
'weblogic.kernel.Default (self-tuning)'] (Mapping.java:84) - [sessionID:
perf-test] [] Base mapping [//LOB/account/accountIdentifier[type='B']] not
found
{quote}
A 2-3 seconds request, when changed to have well formatted 4
XMLGregorianCalendars, ended up taking 53 seconds. (or 400ms > 10 seconds on
our fastest machines).
It only goes this slow when eclipse debug mode shows me XMLGregorianCalendar in
our 'buggy' fields (other times it is just null).
I tried to reproduce it standalone but it seems to not be just
XMLGregorianCalendar... hmm. Maybe was too simple a test object.
JVisualVM says most CPU use is at
org.apache.commons.jxpath.util.ValueUtils.getIndexedPropertyLength(), but
here's a picture of the snapshot: http://i.imgur.com/R8Icx8q.png
> XMLGregorianCalendar existence adding a lot of performance penalty
> --
>
> Key: JXPATH-183
> URL: https://issues.apache.org/jira/browse/JXPATH-183
> Project: Commons JXPath
> Issue Type: Improvement
>Affects Versions: 1.3
> Environment: Windows 7, Amazon Unix, Weblogic
>Reporter: Ganna Shmatova
> Labels: performance
>
> We're using JXPath to parse some input from a client. When they give us a
> valid date it gets transformed from a SOAP message into Java objects. When
> this happens JXPath queries suddenly take 1-8 seconds more (depending on
> system -- the optimized system it's 1 second, dev & test machines it's 8).
> Kicker is, we don't even look for this field. Just its existence does it.
> (we've quickfixed to omit the xml tags before the string is parsed into Java
> for now)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JXPATH-183) XMLGregorianCalendar existence adding a lot of performance penalty
[ https://issues.apache.org/jira/browse/JXPATH-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15023175#comment-15023175 ] Michael Osipov commented on JXPATH-183: --- Did you some micro-benchmarks with an appropriate file? Can you share where the bottleneck is? Did you check it with VisualVM or alike? > XMLGregorianCalendar existence adding a lot of performance penalty > -- > > Key: JXPATH-183 > URL: https://issues.apache.org/jira/browse/JXPATH-183 > Project: Commons JXPath > Issue Type: Improvement >Affects Versions: 1.3 > Environment: Windows 7, Amazon Unix, Weblogic >Reporter: Ganna Shmatova > Labels: performance > > We're using JXPath to parse some input from a client. When they give us a > valid date it gets transformed from a SOAP message into Java objects. When > this happens JXPath queries suddenly take 1-8 seconds more (depending on > system -- the optimized system it's 1 second, dev & test machines it's 8). > Kicker is, we don't even look for this field. Just its existence does it. > (we've quickfixed to omit the xml tags before the string is parsed into Java > for now) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
