directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <akaras...@apache.org>
Subject [ApacheDS] Why was the notAliasCache added to ExceptionUtils?
Date Mon, 04 Aug 2008 02:19:59 GMT
I don't know why this was added instead of adding eager entry loading.  It
was added during one of the 1.5.x iterations.  We should get rid of this
notAliasCache optimization here in ExceptionUtils since all
ContextOperations will soon eagerly load the target entry if present.  The
check for aliases will not incur the overhead that this cache hopes to do
away with.  Instead this eats more memory, more contention, and will
actually cost more in processing time to match the DN.  This is an example
of premature optimization becoming more of a problem then it solves.  Cache
description is here:

    /**
     * A cache to store entries which are not aliases.
     * It's a speedup, we will be able to avoid backend lookups.
     *
     * Note that the backend also use a cache mechanism, but for performance
gain, it's good
     * to manage a cache here. The main problem is that when a user modify
the parent, we will
     * have to update it at three different places :
     * - in the backend,
     * - in the partition cache,
     * - in this cache.
     *
     * The update of the backend and partition cache is already correctly
handled, so we will
     * just have to offer an access to refresh the local cache. This should
be done in
     * delete, modify and move operations.
     *
     * We need to be sure that frequently used DNs are always in cache, and
not discarded.
     * We will use a LRU cache for this purpose.
     */
    private final LRUMap notAliasCache = new LRUMap( DEFAULT_CACHE_SIZE );

:(

This is totally unnecessary and a distraction.  Yeah we get some slight
performance advantage for a few months.  Then it becomes a problem.

If we add temporary solutions then we should make sure we note it in JIRA so
we can later go back and cleanup the workaround.  Also having an issue that
is required to be completed before cleaning up the no longer needed code is
a good idea.  Like for example a "add eager loading of target entries to
OperationContexts" could be an issue that needs to occur before the "Remove
not alias cache in ExceptionInterceptor".

This code (an optimization in dev cycle) though is not a case where it is at
all warranted.  It is an example of a performance improvement that will be
determimental to performance as the architecture shifts to accomodate these
performance bottlenecks.  This is why I fear premature optimizations.
Optimizations need to occur while producing release candidates before a
major GA release, or subsequent to the GA in maintenance releases.  Instead
of optimizing a development branch we need to shift the architecture to fix
the problem.

<main-point>
As a rule we should not optimize in development releases.  Optimization
should be left to RC releases before a GA or in maintenance releases
afterwards.
</main-point>

Thanks,
Alex

-- 
Microsoft gives you Windows, Linux gives you the whole house ...

Mime
View raw message