jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "angela (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-1501) poor performance on big collections
Date Fri, 03 Oct 2008 13:24:44 GMT

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

angela 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.

> 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.

> would just mean that the test would need to be rewritten to use separate sessions. 

whatever you like :)
i didn't try that.

> 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.


Mime
View raw message