Hi Thomas, results look good! I think it's clear that this is not a final and fair comparison, but it's good to be able to see which of the missing features actually makes it more complex and/or slower while they will be implemented.
On Wed, Mar 17, 2010 at 19:42, Thomas Müller <thomas.muel...@day.com> wrote: > I'm wondering what is the *most* problematic features to verify the > architecture: I have no real answer, but just a prioritization what should be fast and what not (I reordered the bullet points accordingly): > - orderable child nodes > - transactions > - clustering > - observation > - correct path parsing and lookup > - multiple sessions > - large number of child nodes (as discussed for jr3) Core features IMO, must be as fast as possible. > - same name siblings > - node types > - locking I think the above features should be "optional" and only add additional computations if used (eg. if a non-nt:unstructured node type is used, etc.). > - security Since this typically has to work on each node/property read, it has a major impact. However, I guess that it is already quite optimized in Jackrabbit 2.0. > - workspaces Shouldn't impact performance - just like a larger number of total nodes in a single workspace should not affect performance. > - search Lies in-between... the problem with search is the (required ?) transactionality on writes. >> cut some features to gian performance improvement. > > I'm not sure. What features could be cut? None, it should still be fully jcr 2.0 compliant. But as we discussed, it can deliberately prefer certain use cases. Regards, Alex -- Alexander Klimetschek alexander.klimetsc...@day.com
