[
https://issues.apache.org/jira/browse/JCR-1501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12636635#action_12636635
]
Julian Reschke commented on JCR-1501:
-------------------------------------
>> But the point of the test was not to test the cache
>
>but that's what the test does in core from my point of view. you don't modify
>anything while executing the test.
>therefore Session.refresh(false) doesn't have to revert any in the core.
In which case I think the test should be rewritten so that separate sessions
are used.
>> So I don't think that enhancements wrt to JCR-1012 will really help
>
>why not? if jcr2spi can find out that nothing changed refreshing a tree
>doesn't do anything. and if something changed the invalidation can be executed
>specifically
>instead of being applied to the complete tree.
It does help in cases where the information being requested was already
requested by the session. But that's not what the point of this benchmark was.
The only reason why it loops is to (a) take care of the potential optimzations
the VM is doing, and (b) to get reliable numbers.
> 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.
