Discussion to reduce garbage collection pressure

[verdie-g]

After migrating to aerospike, a bump of gen 2 collections could be observed which increased the time spent in the gc. Using dotmemory on one of our production service, I can see many aerospike objects collected in gen 2.

For a single aerospike get, many objects are allocated:

• Key
• StringValue
• string (key)
• AsyncRead
• Stopwatch (fixed by https://github.com/aerospike/aerospike-client-csharp/pull/67)
• Partition
• RecordListenerAdapter
• TaskCompletionSource
• Task
• Record
• Dictionary (bins key/value)

Apparently all these objects can reach gen 2 during the round-trip to Aerospike. I'd like to start a discussion about what we can do about it. For example would it be possible to pool Key objects?

[BrianNichols]

I support eliminating memory allocations when possible that do not require extra caching. Your Stopwatch change is a good example of this.

Introducing a key pool cache at the client level might favor applications with a small subset of hot keys, but it will be worse for applications with a large number of diverse keys. I prefer to let the gc do the work as opposed to adding extra processing/code/memory usage in the client.

A key cache can still be implemented at the application level for applications that benefit from it.

[verdie-g]

I haven't found other optimizations because these object instances are either provided by the user or returned to the user so you can't control their lifetime.

A key cache can still be implemented at the application level for applications

Currently a Key is immutable. I think it will be difficult to reuse one with their StringValue by just changing the contained string.

[BrianNichols]

True, pooling Key objects would require the Key fields being mutable. I want to avoid this change because immutability allows the compiler to make other optimizations.

[verdie-g]

Gen 2 is looking way better after #67, #69, #70.