[
https://issues.apache.org/jira/browse/OAK-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13409376#comment-13409376
]
Jukka Zitting commented on OAK-169:
-----------------------------------
bq. Really just curious, but why would a linked list be slower?
The {{O\(n)}} measure I mentioned above is _in terms of nodes accessed_, i.e. n
= number of {{MicroKernel.getNodes()}} calls. We could in principle achieve the
code snippet I included above with just a single {{getNodes()}} call with a
clever filter argument, but even then the underlying MicroKernel implementation
would need to load all child node states in order to be able to return the list
pointers in each child node. With the multi-valued property approach only a
single zero-depth {{getNodes()}} call is needed.
A good example of the kind of performance difference this means in practice is
timing {{ls}} vs. {{ls -l}} of a large directory on a typical Unix file system.
The former requires reading just the directory while the latter requires
accessing also the inodes of all the contained files. On my (oldish) desktop
that's 0.03s vs 0.14s for a directory with 10k files in it.
> Support orderable nodes
> -----------------------
>
> Key: OAK-169
> URL: https://issues.apache.org/jira/browse/OAK-169
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: jcr
> Reporter: Jukka Zitting
>
> There are JCR clients that depend on the ability to explicitly specify the
> order of child nodes. That functionality is not included in the MicroKernel
> tree model, so we need to implement it either in oak-core or oak-jcr using
> something like an extra (hidden) {{oak:childOrder}} property that records the
> specified ordering of child nodes. A multi-valued string property is probably
> good enough for this.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
