jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Klimetschek <aklim...@day.com>
Subject Re: [jr3] MicroKernel prototype
Date Wed, 17 Mar 2010 18:59:41 GMT
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.mueller@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.klimetschek@day.com

Mime
View raw message