[SNMP4J] Reducing temporary object allocations for SNMP4j

[Frank Fock]

Hi Iker,

This is a good point. I have changed the
VariableBinding constructor already to
use Null.instance instead "new Null()".

I have introduced the cloning to avoid
race conditions in multi-threaded
applications.

Introducing a immutable OID subclass
would solve the issue and the user could
choose which one to use. The same would
work for Variable, although here an immutable
wrapper could help too.

Both approaches are not first choice, because
an immutable super class/interface would be
better.

Please let me know if you need more information
on the commercial support. You can order it
online from:
https://agentpp.plimus.com/jsp/dev_store1.jsp?developerId=93158

Best regards,
Frank

Iker Almandoz wrote:
> Hi Frank, 
> 
>  
> 
> I am using SNMP4j to collect huge amounts of SNMP data (approximately 3200
> Million OIDs per day) as part of a commercial application.
> 
>  
> 
> When I create VariableBinding objects, both the OID object and the Variable
> objects get cloned which essentially means that I'm creating 3200 Million
> additional OID objects (with their corresponding int arrays) as well as
> 3200Million new Variable objects.   I'm solving this currently by extending
> both Variable and OID to return a reference to themselves in the clone()
> method and by having a single Null() object such that I don't get a new one
> for each VariableBinding. 
> 
> Is there any way inside of SNMP4j we could use to avoid creating so many
> temporaries ?
> 
> We would prefer to not use workarounds outside of SNMP4j such that we can
> remain fully compatible with the library to be able to benefit from the
> latest updates.
> 
>  
> 
> The garbage collection has become our current bottleneck in our
> implementation where in terms of object creation in bytes we get:
> 
> 48.3% int[] (from OID objects)
> 
> 7.2% BER$MutableByte
> 
> 6.7% OID
> 
> 4.5% VariableBinding
> 
> 3% Integer32.
> 
> 2.2% Null
> 
>  
> 
> We would be interested in getting support from you on this and other issues
> are we are considering on signing for the "SNMP4J annual email support
> package". 
> 
>  
> 
> Best regards, 
> Iker
> 
> _______________________________________________
> SNMP4J mailing list
> SNMP4J at agentpp.org
> http://lists.agentpp.org/mailman/listinfo/snmp4j

-- 
AGENT++
http://www.agentpp.com
http://www.mibexplorer.com
http://www.mibdesigner.com