[
https://issues.apache.org/jira/browse/DIRAPI-318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16594421#comment-16594421
]
Aaron Burgemeister commented on DIRAPI-318:
-------------------------------------------
I'm going to post here since it is where the fix matters, but also on the
Directory Studio bug dealing with slow loading (DIRSTUDIO-1174) because I am so
happy!.
Cloned the API repo, ran a build (not sure I did that properly, but it made my
CPU warm up for a while so it seemed good enough), and then copied JARs until I
found this one copied by this command to where my newly-built Directory Studio
build was waiting:
cp ./ldap/model/target/api-ldap-model-2.0.0.AM2-SNAPSHOT.jar
/home/ab/Desktop/ApacheDirectoryStudio/plugins/org.apache.directory.api.ldap.model_2.0.0.AM1.jar
Summary: Twenty-seven (27) seconds came down to seven (7), which is only a
couple seconds longer than a fresh install with no connections defined. If it
gets better than this, I'll be surprised. Great, wonderful work! I think
people who use Directory Studio at all will notice this difference since we're
going from a one-second penalty per connection with non-default schema, to
something around a 0.05 second penalty (don't check my math).
> Schema elements HashCode are not computed at all
> ------------------------------------------------
>
> Key: DIRAPI-318
> URL: https://issues.apache.org/jira/browse/DIRAPI-318
> Project: Directory Client API
> Issue Type: Improvement
> Affects Versions: 2.0.0.AM1
> Reporter: Emmanuel Lecharny
> Priority: Critical
> Fix For: 2.0.0.AM2
>
>
> The {{SchemaObject}} sub-classes hashCode is never computed, unless the
> {{lock()}} method is called.
> The {{lock()}} method is used to compute this value, but them the object
> isn't mutable anymore. This is ok for the un-mutable flavor, not at all for
> the mutable one, as any attempt to update them will result in a
> {{UnsupportedOperationException}} being thrown, like in :
> {code:java}
> public void setMayAttributeTypeOids( List<String> mayAttributeTypeOids )
> {
> if ( locked )
> {
> throw new UnsupportedOperationException( I18n.err(
> I18n.ERR_13700_CANNOT_MODIFY_LOCKED_SCHEMA_OBJECT, getName() ) );
> }
> if ( !isReadOnly )
> {
> this.mayAttributeTypeOids = mayAttributeTypeOids;
> }
> }
> {code}
> The idea behind not computing teh hashCode on the fly was to speedup the use
> of this class, which is frequently stored in {{Map}} or {{Set}}. The problem
> is that the {{lock()}} method must now be called explicitly *outside* the
> class, which is clearly painful.
> The direct consequence if the {{lock()}} method is not called is that *ALL*
> the {{SchemaElement}} instances will have a hashCode value of {{0}}, making
> the access from a {{Set}}/{{Map}} quite expensive :/
> To add insult to injury, you simply can't call {{lock()}} on a mutable
> version, as it will forbid you to update the object unless you unlock it
> before. Beautiful :/
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
