[
https://issues.apache.org/jira/browse/JCR-1196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12560997#action_12560997
]
Martin Zdila commented on JCR-1196:
-----------------------------------
test method:
-----------------
long time = System.currentTimeMillis();
final String queryString = ...;
final Query query =
session.getWorkspace().getQueryManager().createQuery(queryString, Query.XPATH);
final QueryResult queryResult = query.execute();
System.out.println("t1:" + (System.currentTimeMillis() - time));
time = System.currentTimeMillis();
final NodeIterator ni = queryResult.getNodes();
System.out.println("size:" + ni.getSize());
System.out.println("t2:" + (System.currentTimeMillis() - time));
time = System.currentTimeMillis();
ni.hasNext(); // this single call consumes pretty much time (t3)!
System.out.println("t3:" + (System.currentTimeMillis() - time));
time = System.currentTimeMillis();
for (int i = 0; ni.hasNext() && i < 1000; i++) {
ni.next();
}
System.out.println("t4:" + (System.currentTimeMillis() - time));
results:
--------
Measured second call of the test method (not first which takes longer).
Note that only first test measures t3, because it takes very long time which I
don't have. BTW isn't it another issue?
//gfr:capabilityMap
t1:406
size:11208
t2:0
t3:453864
t4:12
/jcr:root/gfr:devices/gfr:device/gfr:capabilityMap
t1:35358
size:11208
/jcr:root/gfr:devices/gfr:device
t1:169
size:11208
> Optimize queries for DescendantSelfAxisWeight/ChildAxisQuery
> ------------------------------------------------------------
>
> Key: JCR-1196
> URL: https://issues.apache.org/jira/browse/JCR-1196
> Project: Jackrabbit
> Issue Type: Improvement
> Components: jackrabbit-core, query
> Reporter: Ard Schrijvers
>
> A query like
> /documents/en/news//[EMAIL PROTECTED] order by @modificationDate
> when there are many nodes ( > 1.000) in /documents/en/news becomes very
> slow. I think the bottleneck is in something like recursive filters in
> lucene. First off all I'll try to find some stastistics about the
> performance, and describe the bottleneck. After that, a solution must be
> found, where we need to keep in mind that
> 1) these queries run faster and scale better (obviously)
> 2) moving a node must stay a cheap operation
> Also see:
> http://www.nabble.com/Search-performance--%3A-MultiIndex-tf4695559.html#a13421949
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
