[ 
https://issues.apache.org/jira/browse/JCR-1501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12636622#action_12636622
 ] 

Julian Reschke commented on JCR-1501:
-------------------------------------

> i took a closer look at the test cases and came to the conclusion that the 
> performance is lost due to the
> Session.refresh(false) after each iteration, which in jcr2spi invalidates the 
> complete tree and rereads it
> from the SPI upon next access. 

Sure. But the point of the test was not to test the cache, but the performance 
in browsing collections. In general caching will not help in these cases, 
because the request will come from different users (== sessions) and on 
different collections. So I don't think that enhancements wrt to JCR-1012 will 
really help -- it would just mean that the test would need to be rewritten to 
use separate sessions.





> poor performance on big collections
> -----------------------------------
>
>                 Key: JCR-1501
>                 URL: https://issues.apache.org/jira/browse/JCR-1501
>             Project: Jackrabbit
>          Issue Type: Improvement
>          Components: jackrabbit-jcr2spi
>            Reporter: Julian Reschke
>
> With JCR-1437, I have added tests for measuring performance, both using 
> "plain" Jackrabbit and through JCR2SPI.
> There are three tests (inside BigCollectionTest), all creating a collection 
> of 500 nt:file nodes.
> - testGetChildren just instantiates the nodes
> - testBrowseMinusJcrData simulates browsing (getting metadata), but does not 
> read jcr:data
> - testBrowse   simulates browsing (getting metadata), including obtaining the 
> content length (jcr:data)
> The tests can be run using
>   mvn -Dtest=JCRBenchmark test
> under both jackrabbit-core and jackrabbit-jcr2spi.
> The results that I see are:
> For plain Jackrabbit:
> testGetChildren: 0.20 ms per iteration
> testBrowseMinusJcrData: 1.15 ms per iteration
> testBrowse: 2.55 ms per iteration
> With JCR2SPI, I see:
> testGetChildren: 281 ms per iteration
> testBrowseMinusJcrData:  577 ms per iteration
> testBrowse: 643 ms per iteration
> So, at least for these tests, JCR2SPI is several orders of magnitude slower.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to