[SNMP4J] Opportunity to optimize SimpleOIDTextFormat.java, etc.

[Chris Janicki]

Hi,

While poking through some source code to figure something out, I noticed that SimpleOIDTextFormat.toString() could be optimized I think, and without affecting API users' code.

1. It's usually recommended to replace StringBuffer with StringBuilder. (The older StringBuffer was internally synchronized, which Sun acknowledged was overkill, and slow.)  Assuming that appears in other classes too, it could be a no-brainer performance tweak, with no external API change since you don't expose the buffer.

2. When instantiating that buffer, its initial size seems unnecessarily big (10*value.length), especially since we know that first few characters will usually be "1.3.6.1.4" or similar, and except for the enterprise number, I *think* most numbers will be small?  I'd suggest a formula like (10+(value.length-5)*5).  Even simply (5*value.length) would save half the memory allocated for the strings, with internal buffer growth required only rarely, if ever, and with no noticeable difference to API users, other than less memory use and slight performance gain.  


Different topic: I assume others have asked about the use of Vectors for holding PDU VariableBindings, but I just wanted to add my voice that I'd like to see that someday updated to a modern/efficient List collection, e.g. ArrayList.  API users' code might need to be updated, but very minimally.  I don't think users would complain much, in light of another performance boost?


Best regards,
Chris