You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Lucas Theisen <lu...@pastdev.com> on 2015/01/02 16:19:19 UTC
Oid class
I was thinking about optimizing Oid... The Oid class represents OID
values. There is a relatively small finite set of OID values. I was
thinking we could get rid of the constructors and use factory methods
instead. One for getting an Oid by String and one by byte[]. I would then
remove the setters, do the conversion to byte[]/String at construction
time, store both values, and change getOid to return a copy of the byte[]
to make it immutable. Then, the first time an Oid is requested, it would
be constructed, and every following request would get the same object.
This would make comparisons faster and remove conversion time altogether
(other than the first request).
The main problem of doing this is that the current methods/constructors are
public so there is no telling if anybody is using them other than us.
Also, they would all remain in memory (though given the relatively small
number and their small size it should be relatively negligible).
My current reason for wanting to do this is i need to check all extended
requests to see if they are startTLS requests. In order to do that, I have
to wrap the connection and intercept the exteneded function and check the
oid. In the case where an OID object is supplied i need to verify it so I
have to either construct an OID and use equals, or toString the oid and do
a string compare. Both would have cost.
This is almost certainly a premature optimization, but sometimes you just
feel like doing things as efficiently as you can think...
What do you think?
Re: Oid class
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 02/01/15 16:19, Lucas Theisen a écrit :
> I was thinking about optimizing Oid... The Oid class represents OID
> values. There is a relatively small finite set of OID values.
Quite not... OID is supposed to be infinite, and was invented to
represent everything possible.
But...
> I was
> thinking we could get rid of the constructors and use factory methods
> instead.
Yes, that would make a lot of sense. In regard to your first sentence, I
would say we are manipoulating a very small set of OID, there is no need
to create them everytime.
So my +1 to the Factory approach.
> One for getting an Oid by String and one by byte[]. I would then
> remove the setters, do the conversion to byte[]/String at construction
> time, store both values, and change getOid to return a copy of the byte[]
> to make it immutable. Then, the first time an Oid is requested, it would
> be constructed, and every following request would get the same object.
> This would make comparisons faster and remove conversion time altogether
> (other than the first request).
To be frank, stroing the values in a long[] was a double mistake :
- first it's certainly not the right data structure when it comes to be
efficient in Java
- second because an OID number is supposed to be illimited, when long is
limited by nature.
I do think that storing the OID as a STring and as a byte[] makes
totally sense.
>
> The main problem of doing this is that the current methods/constructors are
> public so there is no telling if anybody is using them other than us.
Don't worry too much. Keep them, and mark them as deprecated. Keep in
mind we are still releasing milestone.
One import things though : the setOid() method is controlling that the
OID is valid, not sure it's necessary to keep it.
> Also, they would all remain in memory (though given the relatively small
> number and their small size it should be relatively negligible).
+1. You can also limit the number of OID we keep in memory, using a
cache, but taht would be overkilling, IMO.
>
> My current reason for wanting to do this is i need to check all extended
> requests to see if they are startTLS requests. In order to do that, I have
> to wrap the connection and intercept the exteneded function and check the
> oid. In the case where an OID object is supplied i need to verify it so I
> have to either construct an OID and use equals, or toString the oid and do
> a string compare. Both would have cost.
>
> This is almost certainly a premature optimization, but sometimes you just
> feel like doing things as efficiently as you can think...
No, I think it's a good thing to revisite the existing class, which has
been defined 9 years ago. Actually, it's funny :
http://svn.apache.org/viewvc/directory/sandbox/trunk/asn1-new-codec/src/java/org/apache/asn1/primitives/OID.java?revision=178102&view=markup&pathrev=200000
/**
* Creates a new OID object.
*/
public OID()
{
// We should not create this kind of object directly, it must
// be created through the factory.
}
Re: Oid class
Posted by Lucas Theisen <lu...@pastdev.com>.
On Fri, Jan 2, 2015 at 10:58 AM, Kiran Ayyagari <ka...@apache.org>
wrote:
>
>
> On Fri, Jan 2, 2015 at 11:19 PM, Lucas Theisen <lu...@pastdev.com>
> wrote:
>
>> I was thinking about optimizing Oid... The Oid class represents OID
>> values. There is a relatively small finite set of OID values. I was
>> thinking we could get rid of the constructors and use factory methods
>> instead. One for getting an Oid by String and one by byte[]. I would then
>> remove the setters, do the conversion to byte[]/String at construction
>> time, store both values, and change getOid to return a copy of the byte[]
>> to make it immutable. Then, the first time an Oid is requested, it would
>> be constructed, and every following request would get the same object.
>> This would make comparisons faster and remove conversion time altogether
>> (other than the first request).
>>
>> The main problem of doing this is that the current methods/constructors
>> are public so there is no telling if anybody is using them other than us.
>> Also, they would all remain in memory (though given the relatively small
>> number and their small size it should be relatively negligible).
>>
>> My current reason for wanting to do this is i need to check all extended
>> requests to see if they are startTLS
>>
> you mean if the request issues by client is a StartTLS request or not?
> where do you intend to intercept these
> requests?
>
I would wrap the LdapConnection class and override all (4) of the extended
methods and check the oid:
@Override
public ExtendedResponse extended( Oid oid ) throws LdapException
{
if ( StartTlsRequest.EXTENSION_OID_OBJECT.equals( oid ) ) {
startTlsCalled = true;
}
return connection.extended( oid );
}
then i would know if a startTLS was requested so i can unbind/rebind the
connection before returning it to the pool.
requests. In order to do that, I have to wrap the connection and intercept
>> the exteneded function and check the oid. In the case where an OID object
>> is supplied i need to verify it so I have to either construct an OID and
>> use equals, or toString the oid and do a string compare. Both would have
>> cost.
>>
>> This is almost certainly a premature optimization, but sometimes you just
>> feel like doing things as efficiently as you can think...
>>
>> What do you think?
>>
>
>
>
> --
> Kiran Ayyagari
> http://keydap.com
>
Re: Oid class
Posted by Kiran Ayyagari <ka...@apache.org>.
On Fri, Jan 2, 2015 at 11:19 PM, Lucas Theisen <lu...@pastdev.com>
wrote:
> I was thinking about optimizing Oid... The Oid class represents OID
> values. There is a relatively small finite set of OID values. I was
> thinking we could get rid of the constructors and use factory methods
> instead. One for getting an Oid by String and one by byte[]. I would then
> remove the setters, do the conversion to byte[]/String at construction
> time, store both values, and change getOid to return a copy of the byte[]
> to make it immutable. Then, the first time an Oid is requested, it would
> be constructed, and every following request would get the same object.
> This would make comparisons faster and remove conversion time altogether
> (other than the first request).
>
> The main problem of doing this is that the current methods/constructors
> are public so there is no telling if anybody is using them other than us.
> Also, they would all remain in memory (though given the relatively small
> number and their small size it should be relatively negligible).
>
> My current reason for wanting to do this is i need to check all extended
> requests to see if they are startTLS
>
you mean if the request issues by client is a StartTLS request or not?
where do you intend to intercept these
requests?
> requests. In order to do that, I have to wrap the connection and
> intercept the exteneded function and check the oid. In the case where an
> OID object is supplied i need to verify it so I have to either construct an
> OID and use equals, or toString the oid and do a string compare. Both
> would have cost.
>
> This is almost certainly a premature optimization, but sometimes you just
> feel like doing things as efficiently as you can think...
>
> What do you think?
>
--
Kiran Ayyagari
http://keydap.com