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

_______________________________________________
SNMP4J mailing list
[email protected]
https://s16675406.onlinehome-server.info/mailman/listinfo/snmp4j

Reply via email to