directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lucas Theisen <lucasthei...@pastdev.com>
Subject Oid class
Date Fri, 02 Jan 2015 15:19:19 GMT
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?

Mime
View raw message