jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting" <jukka.zitt...@gmail.com>
Subject Re: Layering the Jackrabbit JCR interface classes
Date Fri, 09 Feb 2007 17:02:15 GMT

On 2/9/07, Stefan Guggisberg <stefan.guggisberg@gmail.com> wrote:
> however, we should IMO be careful not to blindly sacrifice performance
> for cleaner code. a move operation could e.g. be modeled as a copy&delete,
> this might make sense from a design perspective, but not performance wise.

Agreed. The move vs copy&delete case is quite extreme, but even things
like implementing Item.getAncestor(), Item.getPath(), or
Item.getDepth() in terms of Item.getParent() are potential performance
issues. There is however no stopping jackrabbit-core from extending
the adapters and interfaces from the proposed generic solution to
provide implementation-specific improvements for cases where
performance gains are available. Thus I don't think the proposed
solution introduces any design-induced performance issues that
couldn't be easily avoided.

As a general guideline I'd set the maximum allowed performance hit of
the proposed layering to an extra one or two indirect calls per
implemented method. If the performance hit seems worse, then we keep
the current structure.


Jukka Zitting

View raw message